MySQL 迁移 TiDB 最佳指北1 -- 动身前的checklist

🪐 TiDB 技术问题 性能调优
1

tidb 版本为v4.0.7
业务在考虑从mysql5.7 迁移到tidb, 由于tidb 在使用上跟mysql 的一些差异性，我准备了一些checklist。
请再帮忙确认下是否有其他的点需要关注的。或者有其他公司的最佳实践发来参考一下也行。多谢

5.从mysql 迁移到tidb 的使用注意事项 & 改造要点

  • 主键的设计
  • 单行数据的大小限制
  • 字符集 & sql_mode & 大小写
  • 业务SQL建议使用force index方式,避免TiDB的执行计划出现误判(4.0 是否还有计划不准的情况？待验证)
  • sql 兼容性的问题: 比如一些函数是否在tidb中结果符合预期
  • 日期类型的索引的热点问题
  • 字段修改的兼容性问题: tidb 不支持部分字段的修改模型(unsigned,decimal,varchar->int等等)
  • 验证重点表数据的一致性
  • 打通下游大数据订阅tidb 数据的链路: 暂定使用pump & drainer --> kafka
2

与 mysql 兼容性可参考官网，另外官网也有一些其他用户的案例。可以参考一下。
https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility

3

目前我们有个场景是从线上mysql 迁移3T 数据到tidb 。
但是数据同步到tidb 之后，原有表的自增id 的主键如果存在大量的写入热点该如何进行处理 ？

请提供个最佳实践的办法，尽可能减少在将业务从mysql 切换到tidb 时的影响。

4

可以参考文档

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-热点问题处理

https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#热点产生的实例

5

嗯，感谢回复。或许split region 这个是比较好的办法吧。
我的目的是在业务正常写入的情况下尽可能不改变表结构来达到热点的分散。
– auto_random 需要重建表结构
– SHARD_ROW_ID_BITS 的话感觉可以先删除掉自增主键，然后 ALTER TABLE t SHARD_ROW_ID_BITS = 4;
这样会使用隐式的rowid。这样没有定义显示主键的话会有其他的性能问题么？ 比如消费到下游的tidb-binlog 或者是ticdc ？

6

  1. ticdc 要注意同步的限制 和场景
    https://docs.pingcap.com/zh/tidb/stable/ticdc-overview#同步限制

  2. 热点还有一个参数可以试试 Load Base Split
    https://docs.pingcap.com/zh/tidb/stable/configure-load-base-split#场景描述