Upgrades

Transcript

Upgrades are often less time sensitive or critical than updates.

Rather than the motivation being security updates as it is with updates, an upgrade is more forward looking and strategic. The motivation could be for improved compatibility with MySQL, performance enhancements, or an entirely new feature.

In the case of TiDB, you may be planning your upgrade from TiDB 2.0 to 2.1.

Using this as an example, an upgrade to 2.1 would bring you:

• A number of performance enhancements such as a “fast-path” optimization for point lookup queries. For very simple queries, TiDB skips large parts of its optimizer and the co-processor and just retrieves records directly from TiKV, improving performance by up to 40%.
• Improvements for analytics queries, such as improved parallel execution.
• Experimental support for table partitioning.

In most cases, upgrades are a safe and straight forward process. But if you come from a Database Administration background, you probably know it is better to play safe and not rush into an upgrade.

From my experience working on the MySQL Server, the most typical upgrade related issue that I encountered was regressions in query optimization. Because SQL is declarative (as we covered earlier in query optimization), it doesn’t actually instruct how the query should be executed. And while this makes it easier for newer versions of the software to introduce performance improvements, there are edge cases.

It is not unheard of for a new query optimization to make a certain type of query much faster, but also incorrectly be applied in scenarios which make queries slower.

If you have an application that is particularly sensitive to performance regressions, you may want to look at evaluating your upgrade with the help of some third party tools. I will talk about these in more detail in our next video, on migration.