Shadowing Practice: MySQL took 21 years to fix this bug - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

190 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

In my 16 years as a software developer,

nothing made me happier than avoiding an annoying bug long enough for someone else to accidentally fix it,

or for the entire feature to be removed before I ever had to touch that code.

In fact, after years of hard work and dedication,

I can proudly say that I have polished this skill to perfection.

As some of the more experienced among you already know,

avoiding a ticket without looking like you are avoiding a ticket is an art form.

You cannot just ignore it,

because that is amateur work.

A seasoned senior software developer who earns their keep will occasionally comment something vague,

like, I'll have to circle back to it when my priorities allow it,

or this is a tough one,

but I believe I'm finally close to a solution.

Then, they let a little more time pass and hope for the best.

And, hope, as you eventually learn,

is basically at the core of software development.

So when I tell you

that the MySQL team avoided a single bug ticket for 21 years and somehow made it look almost professional,

understand that I say this with deep, deep respect.

When a bug is first reported in 2005,

and you get to fix it in 2026,

we should all sit down,

take notes and learn a thing or two about surviving this industry.

The bug in question is MySQL bug number 11472,

filed on June 21st, 2005.

To give you a sense of how long ago that was,

the iPhone did not exist,

the most popular browser on Earth was Internet Explorer 6

and Sam Altman was busy creating a social network instead of convincing the world

that AI tokens are as important as access to electricity or water.

We see a future where intelligence is a utility,

like electricity or water, and people buy it from us.

Anyway, the reported bug was apparently pretty straightforward.

Triggers were not firing when a foreign key cascade modified a row.

For those unfamiliar with relational databases,

a foreign key is basically a rule that says that this piece of data,

like some orders, depends on some other piece of data, like a customer.

Cascades, on the other hand,

are what happen when the database automatically propagates a change through that relationship.

So when you delete a customer,

the database can be told to automatically delete that customer's orders for you.

Now, there is a whole separate discussion about whether physically deleting records from a database is a bad practice,

but that is not the topic of this video.

Just keep in mind that in many cases,

you are better off keeping the records in the database and using a soft delete instead,

which simply means marking a row as deleted with a boolean flag.

Back to the bug, when one of these automated cascade deletes happens,

my SQL goes and removes the affected child rows for you,

but it does it quietly.

So quietly that the triggers attached to those rows have no idea anything happened.

Triggers, if you have not run into them before,

are little bits of code that you tell the database to run automatically whenever a specific event happens on a specific table.

Again, there is an entire discussion on the topic of best practices

when it comes to triggers and there is an ongoing fight about them in the industry.

The modern application crowd will tell you triggers are invisible,

untestable and a debugging nightmare

and honestly they are not wrong a trigger does not show up in your git dev

or in code review and a new developer joining your team might be surprised to find out

that half the logic of your application is happening inside the database fired off by little scripts

that nobody has looked at for the past 15 years also triggers do not translate

when you migrate from one database to another because every database has its own slightly different trigger syntax.

On the other hand, the database crowd,

mostly old-school DBAs, will tell you

that triggers are the only thing in your entire stack that catches every change to your data,

no matter where it came from.

If you have three different services,

a cron job, and some random script all writing to the same database,

only a trigger sees all the changes reliably.

But enough with the boring theory,

let's get back to the actual bug report.

A few days after the initial report,

the MySQL team says the plan is to fix it in their upcoming 5.1 release.

Again, take notes, because this is the kind of confidence you guys need to succeed in this career.

Then, a few days, sorry,

a few years pass, and in 2007,

a new comment from the team states that MySQL's own foreign key implementation will eventually fix this,

but it will still take some time.

Then, two years later, the confirmation that this bug will not be fixed in 5.1 is posted.

In 2013, 8 years in,

a user asks for an update.

The official reply this time,

and I want you to appreciate the craftsmanship here,

says Note that there is major development work needed to fix this issue,

it will not be a mere bug fix.

At this point, the bug is starting to become somewhat of a meme because a user replies in the thread,

the guys over at Oracle probably aren't getting any of these messages because their triggers aren't firing.

This joke was funny for 13 years straight.

It's important to note that during this time MySQL changed owners multiple times.

It started as an open source database built by a small Swedish company.

It was bought by Sun Microsystems in 2008 for $1 billion,

which at the time felt like a lot of money.

Then, in 2010, Oracle bought Sun and inherited MySQL together with the second best programming language in the world.

And since we are talking about billions of dollars,

please let me tell you a few words about today's sponsor.

PostHog is a platform built to help developers and product managers build their dream projects by helping debug their product,

understand their customers, analyze usage and ship more successful features faster.

They make things really easy for you by putting all the tools and data you need in one place.

This means product analytics, web analytics,

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.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

אותו ערוץ

They want mediocre developers...

Business EnglishUniversity StudentsWorking Adults

FOR YOU

המלץ על סרטון

186 משפטים

Why Shopify Moved Inventory Reservations from Redis to MySQL

Business EnglishUniversity StudentsWorking Adults

270 משפטים

Learning to code: How Pavel Durov learned to program | Lex Fridman Podcast Clips

Business EnglishUniversity StudentsWorking Adults

47 משפטים

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

Business EnglishUniversity StudentsWorking Adults

Why practice speaking with this video?

Engaging with the content of the video titled "MySQL took 21 years to fix this bug" offers a unique opportunity to enhance your English speaking skills. As the speaker shares their experiences in the software development industry, they not only provide insight into technical topics but also showcase conversational nuances that are beneficial for learners. By watching and practicing with this video, you can improve your ability to articulate complex ideas and technical jargon, which is essential for IELTS speaking practice and professional environments.

Additionally, the speaker's use of humor and personal anecdotes makes the content relatable, providing you with an engaging context to practice your spoken English. The idea of "avoiding a ticket" creatively illustrates how seasoned professionals navigate challenges, allowing learners to grasp story-telling elements in English communication. This combination of narrative and technical discussion helps learners expand both vocabulary and ability to express thoughts in varied contexts, making it an effective choice for those looking to learn English with YouTube.

Grammar & Expressions in Context

Throughout the transcript, the speaker employs several key grammatical structures and expressions that can enhance your English speaking proficiency:

Past Perfect Tense: The speaker refers to their experiences with phrases like "I have polished this skill to perfection." This structure emphasizes the completion of an action before another point in the past, useful for narrating personal achievements.
Conditional Sentences: Phrases such as "If you get to fix it" illustrate hypothetical situations. Understanding and utilizing conditionals can help you express possibilities and scenarios succinctly.
Descriptive Language: The speaker employs rich descriptions, such as "avoid an annoying bug long enough." This adds color and detail to communication, making it more engaging and effective in conveying ideas.
Vague Language: The use of non-specific comments like "I’ll have to circle back to it" highlights how native speakers often use indirect language in professional settings. Understanding this nuance can greatly improve your workplace communication skills.

Common Pronunciation Traps

As you practice speaking with this video, be mindful of particular words and phrases that may present pronunciation challenges:

“Cascades”: The 'c' and 's' sounds can be tricky. Practice breaking it down into syllables: cas-cades.
“Propagates”: This word features multiple syllables, making it easy to stumble. Focus on clear articulation and rhythmic pacing: prop-a-gates.
“Deleting”: The 'd' and 'l' sounds in succession can be difficult for learners. Slow down and emphasize each sound to enhance clarity.
“Trivially”: This adverb may trip you up. Try practicing it in sections: triv-i-al-ly, ensuring you articulate each syllable distinctly.

By practicing with these points in mind, you will not only improve your vocabulary but also gain confidence in your speaking abilities, making your english speaking practice sessions more productive. Embrace the content of the video and let it guide your journey toward fluency!

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	be removed · can be told · will not be fixed
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	have polished · have not run · has looked

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: MySQL took 21 years to fix this bug - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

They want mediocre developers...

Why Shopify Moved Inventory Reservations from Redis to MySQL

Learning to code: How Pavel Durov learned to program | Lex Fridman Podcast Clips

The most interesting "hack" in history...

Why Stability Feels Risky in Modern Careers | C1 English Shadowing

Why 95% of Android Developers Get Use Cases Wrong

How Bitcoin Works in 5 Minutes (Technical)

Oh, wait, actually the best Wordle opener is not “crane”…

What is clean code? - Uncle Bob

FullStack Interview Questions (Junior & Mid)

Watch this before you boot up another device

Build a Real-Time Leaderboard on AWS with DynamoDB

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

Why practice speaking with this video?

Grammar & Expressions in Context

Common Pronunciation Traps

דקדוק בסרטון הזה

מהי טכניקת השאדואינג?