for more interesting results, I usually use something like:

SELECT wtimeRounded
, ROUND(pcnt,1) AS totalPcnt
, ROUND(@a := @a + pcnt, 3) AS pcntSum
, cnt
FROM (
SELECT COUNT(*) AS cnt
, CEIL(wtime * 100)/100 AS wtimeRounded
, (COUNT(*) / (SELECT COUNT(*) FROM performance_log_080523) * 100) AS pcnt
FROM performance_log_080523
GROUP BY CEIL(wtime * 100)/100 # HAVING COUNT(*) > 5
ORDER BY wtime2 ASC
) AS tmp1;

which shows percentages divided by specified time interval – useful for generating performance graphs.

you’re right, but just in this particular case. What about:

mysql> SELECT IF(1 = NULL, 1, 0), (1 = NULL);
+——————–+————+
| IF(1 = NULL, 1, 0) | (1 = NULL) |
+——————–+————+
| 0 | NULL |
+——————–+————+
1 row in set (0.00 sec)

I strongly believe that your efforts and contributions are more than well received by MySQL’s team. Yet, I still don’t see results. And now you’re saying that will take a couple of years to re-write the optimizer, on top of the ten years or more that have been spent to bring mysql up to this level. Hmm, isn’t that kind of a long time dedicated to build a, hmm, let’s say strong product?! I know that Rome wasn’t built in a day but still…

Ah, and add to that list the sql layer (a bunch of if/case statements) and the lack of a consistent behaviour across the storage engines, just to start with. Add to my argument the same amount of time I mentioned earlier.

Now that MySQL is part of Sun, they don’t have any excuse: it’s time for MySQL to REALLY shine with a REALLY strong product. Advocate for this and blog about it because you have the means. The users are waiting for maturity as change.

I am constantly providing feedback to the optimizer team of what else could be fixed and believe me they know about a lot of stuff which needs to be done themselves but it takes a lot of time to get done.

Not to mention there are cases which simply can;t be optimized as well as equivalent set of queries without flow control functions.

I think this is an example a retrograde thinking:
“I’m not big fan on flow control functions like IF or CASE used in MySQL Queries as they are often abused used to create queries which are poorly readable as well as can hardly be optimized well by MySQL Optimizer.”

Well, in this case, how about convincing MySQL AB/Sun to write a real optimizer and tackle the root of the problem? Write a Query Optimizer in such way that will handle well those if/case control functions. It’s time for MySQL RDBMS to evolve.

Indeed. Though I do not like “hackish” approach using things side affect way

Oh yes I know

These inclusive times, rather than ranges are OK for me – in fact it is what I would like to know – what percent goes over 0.3 overall – is what is “bad” and when from there I can visually drill down in how bad is it

On a slightly different note, the SQLs just check on the lower limit i.e., IF(wtime>0.3,1,0), instead it should be IF(wtime BETWEEN 0.3 AND 1, 1, 0). Otherwise, your “so-so” results include poor and fatal also. So, in your first query, the ’so-so’ should be around 8%.

Then you’re lucky In this case you can see functions are used in SELECT list this is safe, if they are used in WHERE or JOIN clause it is a big issue

Something like IF(a.field_1>2,a.field2,5)=b.field1 restricts possible order of joins.

If you can fold multiple queries in one (like in this example) it is surely good idea.