New Rules for pt-query-advisor

Registered by Daniel Nichter

Add new rules for pt-query-adivsor to the whiteboard, and remove them once they're implemented.

OBSOLETE: All these rules were moved to https://github.com/percona/query-advisor/issues

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Daniel Nichter

Related branches

Sprints

Whiteboard

* Duplicate columns
Example: select a.*, a.foo from mytable;
See: http://www.xaprb.com/blog/2009/08/07/finding-queries-with-duplicate-columns/

* Multi-column IN clause
See: http://www.mysqlperformanceblog.com/2008/04/04/multi-column-in-clause-unexpected-mysql-issue/

* TO_DAYS(column) < TO_DAYS(NOW()) - 5 is a bad habit.

* Generally try to catch when predicates are not sargable because the (possibly indexed) column is not a "bareword".* Statistically speaking, DATE_FORMAT() or TO_DAYS() are bad habits.* COUNT(col). There's an example in Percona issue 3379.
* COUNT(*) itself is often a problem.
* GROUP_CONCAT() is vulnerable to overflowing group_concat_max_len.

* Look for "derived table" subqueries that have no aggregation or LIMIT inside t
hem. (it's also valid to have a derived table subquery that has
DISTINCT inside it, even without LIMIT or GROUP BY, because it's akin to GROUP B
Y)
* Detect a LEFT JOIN where the right-hand-side of the join is never used
* Too many LEFT JOIN are suspicious

* Find weird things that might look like mistakes, such as tables being joined i
n a "leapfrog" manner
See http://code.google.com/p/maatkit/issues/detail?id=1126
* Queries against INFORMATION_SCHEMA.TABLES (and a couple other key views) are catastrophically bad in 5.0, and in 5.1 too unless they are written very carefull
y
* count(<const>) should be count(*)* Alert when a query joins tables on differing data types, character sets.

* Query examined almost 200k rows and sent 2; non-ratio-based advice on this (i.
e. examining 100 rows and sending 1 is not a problem, but examining 100k rows an
d sending 1k is).

* WARN. Ambiguous operator precedence. Mixing AND/OR without parentheses is di
fficult for humans to understand and might indicate the presence of a bug or SQL
 injection.
Example: WHERE a = b AND b = 1 OR c = 2

* if you GROUP BY something that's constrained to be a constant, you should really not GROUP BY it.
Example: SELECT cola, MAX(colb) FROM table WHERE cola = 123 GROUP BY cola;
https://bugs.launchpad.net/percona-toolkit/+bug/996069

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.