Timeline for Walking a BTREE index as far as possible in MySQL
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2013 at 18:55 | history | edited | user6263 | CC BY-SA 3.0 |
added 192 characters in body
|
| Jan 23, 2013 at 18:41 | comment | added | user6263 | If you check the explain plan for your query, it's executing every case statement no matter what the results, so you're actually running 7 queries for a 6 letter word. This isn't optimal. The only reason it works fast is because mysql will fail fast once it gets outside of the matching. | |
| Jan 23, 2013 at 18:00 | comment | added | user6263 | I don't believe that's truly the case. MySQL will walk the tree during the query optimization step and fail fast if the value is missing vs returning all the data for all the hits until it fails. | |
| Jan 23, 2013 at 9:15 | comment | added | eggyal | Whether it is best to start searching from the longest substrings to the shortest (or vice-versa) is an heuristic dependent on the particulars of the problem at hand. In the case of the problem that triggered this question (to which I linked), it is best to start shortest-first. | |
| Jan 23, 2013 at 2:52 | history | answered | user6263 | CC BY-SA 3.0 |