Shadowing Practice: MySQL took 21 years to fix this bug - Learn English Speaking with Video
Les maken...
1
In my 16 years as a software developer,
2
nothing made me happier than avoiding an annoying bug long enough for someone else to accidentally fix it,
3
or for the entire feature to be removed before I ever had to touch that code.
4
In fact, after years of hard work and dedication,
5
I can proudly say that I have polished this skill to perfection.
6
As some of the more experienced among you already know,
7
avoiding a ticket without looking like you are avoiding a ticket is an art form.
8
You cannot just ignore it,
9
because that is amateur work.
10
A seasoned senior software developer who earns their keep will occasionally comment something vague,
11
like, I'll have to circle back to it when my priorities allow it,
12
or this is a tough one,
13
but I believe I'm finally close to a solution.
14
Then, they let a little more time pass and hope for the best.
15
And, hope, as you eventually learn,
16
is basically at the core of software development.
17
So when I tell you
18
that the MySQL team avoided a single bug ticket for 21 years and somehow made it look almost professional,
19
understand that I say this with deep, deep respect.
20
When a bug is first reported in 2005,
21
and you get to fix it in 2026,
22
we should all sit down,
23
take notes and learn a thing or two about surviving this industry.
24
The bug in question is MySQL bug number 11472,
25
filed on June 21st, 2005.
26
To give you a sense of how long ago that was,
27
the iPhone did not exist,
28
the most popular browser on Earth was Internet Explorer 6
29
and Sam Altman was busy creating a social network instead of convincing the world
30
that AI tokens are as important as access to electricity or water.
31
We see a future where intelligence is a utility,
32
like electricity or water, and people buy it from us.
33
Anyway, the reported bug was apparently pretty straightforward.
34
Triggers were not firing when a foreign key cascade modified a row.
35
For those unfamiliar with relational databases,
36
a foreign key is basically a rule that says that this piece of data,
37
like some orders, depends on some other piece of data, like a customer.
38
Cascades, on the other hand,
39
are what happen when the database automatically propagates a change through that relationship.
40
So when you delete a customer,
41
the database can be told to automatically delete that customer's orders for you.
42
Now, there is a whole separate discussion about whether physically deleting records from a database is a bad practice,
43
but that is not the topic of this video.
44
Just keep in mind that in many cases,
45
you are better off keeping the records in the database and using a soft delete instead,
46
which simply means marking a row as deleted with a boolean flag.
47
Back to the bug, when one of these automated cascade deletes happens,
48
my SQL goes and removes the affected child rows for you,
49
but it does it quietly.
50
So quietly that the triggers attached to those rows have no idea anything happened.
51
Triggers, if you have not run into them before,
52
are little bits of code that you tell the database to run automatically whenever a specific event happens on a specific table.
53
Again, there is an entire discussion on the topic of best practices
54
when it comes to triggers and there is an ongoing fight about them in the industry.
55
The modern application crowd will tell you triggers are invisible,
56
untestable and a debugging nightmare
57
and honestly they are not wrong a trigger does not show up in your git dev
58
or in code review and a new developer joining your team might be surprised to find out
59
that half the logic of your application is happening inside the database fired off by little scripts
60
that nobody has looked at for the past 15 years also triggers do not translate
61
when you migrate from one database to another because every database has its own slightly different trigger syntax.
62
On the other hand, the database crowd,
63
mostly old-school DBAs, will tell you
64
that triggers are the only thing in your entire stack that catches every change to your data,
65
no matter where it came from.
66
If you have three different services,
67
a cron job, and some random script all writing to the same database,
68
only a trigger sees all the changes reliably.
69
But enough with the boring theory,
70
let's get back to the actual bug report.
71
A few days after the initial report,
72
the MySQL team says the plan is to fix it in their upcoming 5.1 release.
73
Again, take notes, because this is the kind of confidence you guys need to succeed in this career.
74
Then, a few days, sorry,
75
a few years pass, and in 2007,
76
a new comment from the team states that MySQL's own foreign key implementation will eventually fix this,
77
but it will still take some time.
78
Then, two years later, the confirmation that this bug will not be fixed in 5.1 is posted.
79
In 2013, 8 years in,
80
a user asks for an update.
81
The official reply this time,
82
and I want you to appreciate the craftsmanship here,
83
says Note that there is major development work needed to fix this issue,
84
it will not be a mere bug fix.
85
At this point, the bug is starting to become somewhat of a meme because a user replies in the thread,
86
the guys over at Oracle probably aren't getting any of these messages because their triggers aren't firing.
87
This joke was funny for 13 years straight.
88
It's important to note that during this time MySQL changed owners multiple times.
89
It started as an open source database built by a small Swedish company.
90
It was bought by Sun Microsystems in 2008 for $1 billion,
91
which at the time felt like a lot of money.
92
Then, in 2010, Oracle bought Sun and inherited MySQL together with the second best programming language in the world.
93
And since we are talking about billions of dollars,
94
please let me tell you a few words about today's sponsor.
95
PostHog is a platform built to help developers and product managers build their dream projects by helping debug their product,
96
understand their customers, analyze usage and ship more successful features faster.
97
They make things really easy for you by putting all the tools and data you need in one place.
98
This means product analytics, web analytics,
99
session replay, error tracking, experimentation,
100
feature flags, LLM analytics, surveys and many more.
101
Then, they give you an actually useful AI agent to make sense of it all.
102
PostHog's data infrastructure is tailored for data engineers who need to build a robust
103
and flexible data stack to house all their business data.
104
And since all data lives on the same platform,
105
you can watch what users actually did,
106
see where they got stuck,
107
roll out a fix behind the feature flag,
108
test whether it worked, and then use the same data to decide what to build next.
109
The setup is as simple as installing one of the available SDKs or pasting a snippet into your site header,
110
which will then auto-capture data like page views, button clicks and sessions.
111
So, if you are building a product and want analytics,
112
replay, flags, experiments, errors, surveys and AI-powered insights without stitching together 5 different tools,
113
please check out PostHog using the link below.
114
Back to the video, by 2015,
115
the comment section enters its second phase when users start showing up on the bug's birthday to leave congratulatory messages like,
116
Happy Anniversary, it's 10 years already,
117
this defect is going to be attending middle school in the fall and happy 13th birthday they grow up so fast.
118
By 2020, we hit a third phase.
119
A user writes, this bug is older than me.
120
The original reporter, who filed a bug in 2005,
121
gets pinged by someone asking if he's still alive
122
and he shows up the next day to confirm he is still using MySQL.
123
Now, jokes aside, the reason this bug took 21 years to fix is actually pretty interesting
124
and it traces its roots in an architectural decision made in the late 90s
125
that turned out to be very hard to walk back.
126
To explain what happened, I need to tell you a little about how MySQL is built,
127
because once you understand the structure,
128
the whole bug starts to make sense.
129
MySQL is built into layers.
130
On top, you have what is called the SQL layer,
131
sometimes also called the server layer.
132
This is the part of MySQL that takes your queries,
133
parses them, plans how to execute them,
134
and then asks for the data.
135
It is also the part that handles things like triggers,
136
views, stored procedures and user permissions.
137
Anything that thinks in terms of SQL statements lives here.
138
Underneath, you have the storage engine.
139
The storage engine is the part that actually reads and writes the bytes on disk.
140
This component deals with pages, indexes, logs and transactions.
141
My SQL is unusual because its storage engine is pluggable,
142
which means you can swap it out,
143
but for the past 15 years,
144
everyone has been using InnoDB.
145
Now, in most databases, foreign keys live in the SQL layer.
146
This layer knows about the foreign key,
147
this layer enforces it, and when a cascade fires,
148
this is the layer that generates the cascade operation as if it were a normal SQL statement.
149
As a result, triggers fire normally,
150
because triggers are also a SQL layer concept.
151
MySQL on the other hand implemented foreign keys inside the InnoDB storage engine.
152
The reason is historical and this is also your awesome trivia for the day.
153
Early versions of MySQL did not support foreign keys at all.
154
The MySQL team famously did not really believe in them
155
and you can actually find a page in their version 3 manual titled Reasons not to use foreign keys.
156
Their arguments age like milk.
157
The first reason they mentioned in the manual is
158
that foreign keys make life very complicated because the foreign key definitions must be stored in a database.
159
The second reason was that foreign keys are slow and unnecessary and you,
160
the developer, will simply remember to insert records in the right order.
161
So when they finally added foreign key support,
162
they bolted it onto InnoDB,
163
because InnoDB was the only engine at the time that supported transactions.
164
The SQL layer was never involved,
165
so foreign keys became strictly an InnoDB feature.
166
So when you run a query such as this one,
167
here is what actually happens step by step.
168
The SQL layer parses your query,
169
it fires the before delete trigger if it exists,
170
then it hands the actual delete operation to InnoDB.
171
InnoDB then notices, on its own,
172
that there is a foreign key with onDelete cascade pointing at the orders table.
173
So it walks the orders table,
174
finds all the orders that belong to that customer and deletes them itself right there in the storage engine.
175
But then, the engine never bubbles back up to the SQL layer to notify it about the additional deletions.
176
So the SQL layer, sitting up there with all the triggers,
177
is perfectly willing to fire them,
178
waiting for someone to tell it that rows on the orders table have changed.
179
This was the issue, and as you can see,
180
this is what the MySQL team meant in 2013,
181
when they wrote that this was not a mere bug fix,
182
but major development work.
183
The two systems that need to talk to each other are architecturally separated.
184
And to finally fix the problem,
185
the team did the thing they had been putting off for 21 years.
186
They moved foreign keys out of InnoDB and up into the SQL layer.
187
If you liked this video,
188
you should consider joining our community where I'm posting more dedicated weekly content.
189
Please don't forget to smash all the buttons and until next time,
190
thank you for watching.
📺 Zelfde Kanaal
✨ Aanbevolen Video
B29
178 zinnen
25 crazy software bugs explained
American AccentBusiness EnglishUniversity StudentsWorking Adults
C11
186 zinnen
Why Shopify Moved Inventory Reservations from Redis to MySQL
Business EnglishUniversity StudentsWorking Adults
C11
315 zinnen
how AI broke the SWE Career Ladder
Business EnglishUniversity StudentsWorking Adults
C11
207 zinnen
How I Made $30,000 Hacking Broken Access Control
Business EnglishUniversity StudentsWorking Adults
C11
156 zinnen
SELECT COUNT (*) can impact your Backend Application Performance, here is why
Business EnglishUniversity StudentsWorking Adults
C11
77 zinnen
The Secret Sauce Behind NoSQL: LSM Tree
Business EnglishUniversity StudentsWorking Adults
C11
54 zinnen
Traceroute: You're Probably Reading the Results Wrong
Business EnglishUniversity StudentsWorking Adults
C11
146 zinnen
🚫 Java Deadlock Explained: Why Your Code is Stuck 😱 (Beginners Must Watch!)
Business EnglishUniversity StudentsWorking Adults
C11
270 zinnen
Learning to code: How Pavel Durov learned to program | Lex Fridman Podcast Clips
Business EnglishUniversity StudentsWorking Adults
C11
78 zinnen
The easy way to keep your repos tidy.
Business EnglishUniversity StudentsWorking Adults
C12
43 zinnen
SDLC Vs STLC: Software Development Life Cycle and Software Testing Life Cycle
Business EnglishUniversity StudentsWorking Adults
C13
53 zinnen
System Design Was HARD - Until You Knew the Trade-Offs
Business EnglishUniversity StudentsWorking Adults
Woordenschat en spreektips bij deze les
Deze spreekles op niveau C1 is gebaseerd op de video “MySQL took 21 years to fix this bug”. Deze woorden komen het vaakst terug: bug, trigger, foreign, key, database. Deze video bevat 190 zinnen en 1980 woorden om na te spreken. Het gesproken deel duurt 10:16. De spreker praat snel, ongeveer 193 woorden per minuut, dus reken op verbonden en ingeslikte klanken. Slechts 80% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden, dus de woordenschat is pittig.
Belangrijke woorden in deze video
De 15 moeilijkste woorden uit de video, met uitspraak en betekenis:
| Woord | Uitspraak | Betekenis |
|---|---|---|
| cascade zelfstandig naamwoord | /kæsˈkeɪd/ | waterval |
| query zelfstandig naamwoord | /ˈkwɪɹ.i/ | vraag, verzoek |
| debug werkwoord | /diːˈbʌɡ/ | debuggen |
| parse werkwoord | /pɑɹs/ | analyseren, ontleden |
| stack zelfstandig naamwoord | /stæk/ | stapel |
| automate werkwoord | /ˈɔ.təˌmeɪt/ | automatiseren |
| craftsmanship zelfstandig naamwoord | /ˈkɹæfts.mən.ʃɪp/ | vakmanschap |
| deletion zelfstandig naamwoord | /dɪˈliːʃən/ | verwijdering |
| migrate werkwoord | /maɪˈɡɹeɪt/ | migreren |
| propagate werkwoord | /ˈpɹɒpəˌɡeɪt/ | propageren |
| snippet zelfstandig naamwoord | /ˈsnɪpɪt/ | fragment |
| trivia zelfstandig naamwoord | /ˈtɹɪvi.ə/ | trivia |
| inherit werkwoord | /ɪnˈhɛɹɪt/ | erven |
| syntax zelfstandig naamwoord | /ˈsɪn.tæks/ | syntaxis |
| tailor zelfstandig naamwoord | /ˈteɪlɚ/ | kleermaker, kleermaakster |
Phrasal verbs die je zult horen
| Woord | Betekenis |
|---|---|
| check out werkwoord | onderzoeken |
| find out werkwoord | ontdekken, onderzoeken |
| grow up werkwoord | opgroeien |
| show up werkwoord | tentoonstellen |
| sit down werkwoord | gaan zitten |
Grammatica in deze video
De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:
| Structuur | In de video |
|---|---|
| Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet | be removed · can be told · will not be fixed |
| Present perfect have/has + voltooid deelwoord — iets uit het verleden dat nu nog telt | have polished · have not run · has looked |
Uitspraak om op te letten
De spreker gebruikt 6 samentrekkingen en verkorte vormen, zoals aren't, I'm, don't. Spreek ze kort uit, zoals je ze hoort.
- De klanken “sh” en “zh”: craftsmanship /ˈkɹæfts.mən.ʃɪp/, deletion /dɪˈliːʃən/, experimentation /ɪkˌspɛɹ.ə.mənˈteɪ.ʃən/, dedication /ˌdɛdɪˈkeɪʃən/, perfection /pɚˈfɛk.ʃən/
- Lange woorden — let op de klemtoon: analytics /ˌæn.əˈlɪt.ɪks/, architecturally /ɑɹ.kɪˈtɛk.t͡ʃɚ.ə.li/, congratulatory /kənˈɡɹæt͡ʃələˌtɔɹi/, experimentation /ɪkˌspɛɹ.ə.mənˈteɪ.ʃən/, unfamiliar /ˌʌnfəˈmɪli.ə(ɹ)/
Klanken die Nederlandstaligen lastig vinden:
- Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: cascade /kæsˈkeɪd/, debug /diːˈbʌɡ/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/, analyze /ˈæn.əˌlaɪz/, vague /veɪɡ/
- /æ/ — opener dan de Nederlandse “e”: cascade /kæsˈkeɪd/, analytics /ˌæn.əˈlɪt.ɪks/, stack /stæk/, congratulatory /kənˈɡɹæt͡ʃələˌtɔɹi/, craftsmanship /ˈkɹæfts.mən.ʃɪp/
- /g/ — een harde plofklank, geen Nederlandse “g”: debug /diːˈbʌɡ/, congratulatory /kənˈɡɹæt͡ʃələˌtɔɹi/, migrate /maɪˈɡɹeɪt/, propagate /ˈpɹɒpəˌɡeɪt/, vague /veɪɡ/
Zo oefen je met deze video
- Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
- Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
- Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als cascade, query, debug.
Wat is de Shadowing-techniek?
Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.