New Rules for pt-query-advisor
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:/
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
- Started by
- Completed by
- Daniel Nichter
Related branches
Related bugs
Sprints
Whiteboard
* Duplicate columns
Example: select a.*, a.foo from mytable;
See: http://
* Multi-column IN clause
See: http://
* 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_
* 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://
* Queries against INFORMATION_
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:/