TiDB丨 从MySQL迁移至TiDB的常见问题及解决方案

本期内容

数据库迁移问题及解法

GC设置过长的问题

由于这套系统之前是跑在MySQL上，所以初期数据库的一些工作，是由MySQL的DBA和我们TiDB团队一起协作完成的。

某一天我们突然发现，集群的druation突然上升，并且是在没有更多请求的情况下，延迟上升了。

经排查发现，是MySQL的dba为了在数据库中保存最近7天的数据，并且实现误操作闪回，将 tidb_gc_life_time 这个参数由1h改成了7d，从而导致tikv中历史版本过多，导致每次磁盘读取会扫描过多的无用数据，导致的整体变慢。

为什么在MySQL里可设置

保留更多的历史数据，而TiDB不行？

基于 MySQL DBA 的操作，我思考了一下：为什么它直接就将GC保留的时间设置长了？

研究发现，MySQL的闪回是通过本地保存binlog日志实现的，且MySQL中，事务的一致性读是通过undo log实现的，所以这里并不会显著的影响正常数据的查询。

而在TiDB中，闪回和一致性读是直接依赖本地保留的历史版本数据，直接保存各个版本数据，实现mvcc，再通过GC定期清除历史版本数据。

MySQL在进行mvcc控制的时候，读取历史的版本依赖的是：事务开始时间戳、当前的数据、undo log日志链。

在事务中在读取历史版本数据时，会先找到最新的数据，依靠每行数据自带的回滚指针，去undo log 中找到事务开始时间戳前最近的一个版本，按时间有序的链表查找历史数据。

而在TiDB中，所有的dml操作都转化为在磁盘中进行追加一行新的数据，最新的数据和历史版本的数据都保留在一起了。

在读取数据时，会先将附近版本的数据全部读取，再根据所需版本进行过滤，这样当保留了过多版本的历史数据时，每次读取都会读取很多无用的数据，造成性能开销。

TiDB中历史版本过多问题及排查方法

SQL调优方式对比

和SQL调优方法

SQL作为和数据库交互的标准语言，SQL调优是DBA以及数据库使用者绕不开的东西。

这里我们看看相比于MySQL的SQL调优方式，在TiDB中的不同之处，以及将业务从MySQL迁移到TiDB后，SQL方面需要做的一些工作。

日常SQL调优分析对比

MySQL迁移到TiDB后

可能会遇到的一些SQL调优的工作

在MySQL迁移至TiDB后，有一部分原来执行没有性能问题的SQL，在TiDB中出现了性能问题，主要有如下：

# 1 偶发性的复杂SQL的连接算子不合理

# 2 SQL执行逻辑不佳

在部分复杂SQL中，在不影响SQL最终结果的前提下，先过滤计算某一部分结果作为临时表，会使整个sql的效率提高。

在部分场景中，MySQL优化器能自动优化处理，TiDB的执行计划不太合理。

解决方案：这种通常只有改写SQL，在SQL中去显示的制作临时表。

# 3 部分小bug

这种问题通常指某些SQL导致的异常行为，多在后续版本中被修复了。例如某些场景下index hash join算子会存在一些问题，通过hint其他算子可绕过。

解决方案：在github搜索相关issue或者pr，或者社区提问。

热点问题

相比于单机的MySQL数据库，分布式TiDB优势之一就是可以利用分布式集群多机器的能力，来突破单机的瓶颈。

但在某些时候，由于数据分布不合理，或者是业务专一的访问某一小部分的数据，这种时候可能会导致分布式集群中单机的瓶颈成为整个集群的瓶颈，这就是热点问题。

热点的排查与解决

但是有时候，我们很难去确认哪些流量才是真正达到了某一单机器的瓶颈，我这里提供一个方法：

大范围热点处理

通常碰到这种类似问题之后，根据热力图中的表名去查询相关的SQL，去验证执行计划中是否走了索引，后续添加索引。

也有一部分为SQL写的不合理，每次请求大量的数据，到应用服务器之后再进行过滤，这种就需要与开发进行讨论添加过滤条件。

写在最后