Expression #1 of SELECT list is not in GROUP By clause
This MySQL error isn’t as hard as you might think to solve. Let’s find out why it’s happening and what we can do to fix it.
These blog entries are tagged “mysql” after the MySQL database. However, they’re likely somewhat interchangeable with the content in the SQL tag and are often grouped together.
This MySQL error isn’t as hard as you might think to solve. Let’s find out why it’s happening and what we can do to fix it.
I guess I should RTFM more often… but I didn’t remember (or know??) that MySQL truncate table
causes an implicit commit.
By now, you’ve probably written many database migrations in Laravel. But, then something else happens. Perhaps your business model changed, your data attributes changed or you’re just refactoring to a stronger architecture. Doesn’t matter which, you’re going to need to convert and migrate some data.
The other day I was at a coffee shop and I looked around at all the Mac’s open. It used to be that you’d see people writing manuscripts at coffee houses. Surprisingly, this place held a lot of programmers. I suddenly thought of something interesting:
Measurement is important. Metrics, while not sexy, are concrete to a good business strategy. When you bring a problem to your superiors, they’re going to want to know what is your measurement, what metrics did you use to determine this is a problem. With tasks I’ve given developers, I’ve always said “show me the metrics that your fix is better” versus just looking at the code.
Here is an interesting proof of concept that the ‘rows’ column of the explain output is actually an estimate, and not the real amount. I KNEW it to be true, but somehow I didn’t feel like it was right. I always thought “the closer the rows # gets to the exact amount of retrieved data, the better. Exact is what you strive for.” Turns out, that’s not true. The closer the number, the better, but its still just an estimation. Sometimes its estimated accurately, other times its not. See this example:
I’m no sys admin, so I can’t be sure, but I’ve seen lots of issues with using things like MySQL Proxy to fully separate the write and read queries in an application. Maybe it works, I don’t know… but I do know that if I can separate the connections in my code, that saves my Admin time… it doesn’t appear to give that much of a hit to performance either! Do keep in mind that this is only working at the table level in Zend Framework. If you use their database system, this should do the trick. If you do a lot of getting the adapter yourself, this won’t help you at all!
The last time I created a char(1)
for a flag field, I remembered the MySQL BIT field - so I did a bit of investigation. I thought, well if I can make a bit field of one bit that is either 0/1, I can save data space in my db.
So the other night I was thinking about using xdebug on my PHP code. I then totally had a brain explosion: I’m always forgetting to profile my MySQL queries. explain
is a great command for this. However, as the lazy programmer I am, I don’t know if I’m always going to do this on all of my queries. In an attempt to save myself time, I started brainstorming an idea.
As you probably know by now, I’m a huge fan of Eclipse PDT. Well, I wanted to stop using MySQL GUI tools for a bit and explore Eclipse tools.
Every once in a while, I forget about the built in awesomeness of MySQL. Today, I was looking at a unix timestamp from PHP in one of the fields and was wondering what that date was. Derr, use from_unixtime function!
There are a few quick ways to monitor MySQL performance. This isn’t much of an in-depth reference, just a quick reminder. Let’s look:
After looking at the Windows model for controlling file access, I realized I could also do that for user authorization control.
I’ve been wondering if I should be concerned about re-preparing a prepared statement when using PDO. Right now, I use code like this when preparing a statement: