You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/book-2.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -178,13 +178,13 @@ Instead, sort (1) init time includes both index range scan (0) read time and tim
178
178
Since index range scan (0) read time is only time spent fetching rows, we can subtract it from sort (1) init time to roughly calculate time spent sorting rows: 2043.416 − 1996.350 = 47 ms.
Alas, the aforementioned means that my original explanation on page 70 of <a href="https://oreil.ly/efficient-mysql-performance"><i>Efficient MySQL Performance</i></a> is not accurate.
184
184
I wrote that "the filesort (line 1) started after [2043.416] milliseconds and ended after [2051.792] milliseconds, which means the filesort took 8 milliseconds."
185
185
The conclusion is still correct: "The answer is no: filesort does not make this query slow. The problem is data access: 68,439 rows is not a small result set."
186
186
But how I arrived at the conclusion was incorrect.
187
-
</p>
187
+
</div>
188
188
</div>
189
189
190
190
The moral of the story is: sometimes you need to understand how iterators work under the hood (in the MySQL source code) in order to correctly interpret the reported timing values.
Copy file name to clipboardExpand all lines: content/infamous-order-by-limit-query-optimizer-bug.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -370,15 +370,15 @@ If you win, nothing will happen; performance will stay the same.
370
370
If you lose, you can quickly re-enable it, or use `FORCE INDEX` to force the secondary index (use `EXPLAIN` to see what it is before MySQL changes the plan).
Disabling <code>prefer_ordering_index</code> in MySQL ≤ 8.0.39 causes another bug: MySQL does not scan the primary key for <code>SELECT ... FROM t ORDER BY pk_col LIMIT n</code>.
376
376
Instead, it does a <em><b>full</b> table scan</em> plus sort, which is unnecessary and very likely to cause problems.
377
377
Unlike the main subject of this blog post, I would call this a real bug.
378
378
Thank you to Jay Janssen and Morgan Tocker for brining this to my attention.
379
379
<br><br>
380
380
I fixed <a href="https://bugs.mysql.com/bug.php?id=113699">this bug</a> in MySQL 8.0.40.
381
-
</p>
381
+
</div>
382
382
</div>
383
383
384
384
Bottom line: you may never be bitten by the infamous ORDER BY LIMIT query optimizer bug, but if you are, you can disable the optimizer flag, or workaround by increasing the `LIMIT` value to change the cost calculations, or use `FORCE INDEX` to force the original secondary index.
Copy file name to clipboardExpand all lines: content/lessons-from-20-years-hacking-mysql-part-1.md
+6-11Lines changed: 6 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -119,13 +119,13 @@ But overall I've been successful thanks to a slim majority of random good luck:
119
119
This is true for my 20 years with MySQL, my whole career, and my whole life.
120
120
All the biggest successes of my life started with random good luck: right place, right time, right people—that kind of thing.
121
121
122
-
Good luck opens doors, but you have to walk through and hike the hill or climb the mountain on the other side.
122
+
Good luck opens doors, but you have to walk through and climb the mountain on the other side.
123
123
That's where the 47% hard work and patience comes in: all the success stories I know took at least 5 years, but 10 years is more typical.
124
124
It takes time to build value, and even longer to change the way people work.
125
125
126
126
And 2% skill?
127
127
At this point in my career, I hope it's not a conceit to say that I've got more skill than that.
128
-
But along the way—hiking the hill or climbing the mountain—success is built by operating a little beyond the current limits.
128
+
But along the way—climbing the mountain—success is built by operating a little beyond the current limits.
129
129
Or, as David Bowie said:
130
130
131
131
> If you feel safe in the area you’re working in, you’re not working in the right area. Always go a little further into the water than you feel you’re capable of being in. Go a little bit out of your depth. And when you don’t feel that your feet are quite touching the bottom, you’re just about in the right place to do something exciting.
@@ -154,7 +154,7 @@ But if you don't tilt the field in your favor, then you have even odds of succes
154
154
If biasing towards success sounds like a "pick yourself up by the bootstrap" cliché, then think of it like a video game: you know success is possible (it's programmed into the game), but you have to complete quests, get items, defeat bosses, and gain skills and experience.
155
155
After awhile, success comes easily because you're a high-level player.
156
156
157
-
Real life is surprising like a video game.
157
+
Real life is surprisingly like a video game.
158
158
Success is possible; it's even programmed into the "game" because most people and most of the world wants you to succeed.
159
159
But there are definitely enemies and bosses—competition and people who don't want you to succeed—which is why success takes work.
160
160
@@ -201,7 +201,9 @@ It will protect you from every attack at work.
201
201
It will attract all the best people and opportunities to you.
@@ -353,10 +355,3 @@ Learning how to raise issues and call out problems _without_ being be labeled a
353
355
As an engineer who builds and fixes things, the temptation to fix the business is powerful, but until you have that skill, tread very lightly and hold onto your [magical shield](#shield).
354
356
355
357
[^7]: Rule #1 for raising issues or calling out problems without being be labeled a naysayer or obstructionist: _offer realistic solutions or ways to improve_.
<ahref="https://www.oreilly.com/library/view/efficient-mysql-performance/9781098105082/ch01.html">Chapter 1</a> of my book <i>Efficient MySQL Performance</i>.
<ahref="https://www.oreilly.com/library/view/efficient-mysql-performance/9781098105082/ch01.html">Chapter 1</a> of my book <i>Efficient MySQL Performance</i>.
0 commit comments