为什么我们要从MySQL迁移到TiDB？( 六 ) _MySQL

根据 table_id 去通过 information_schema.tables 表查一下，可以通过上述方式来定位到是哪张表导致的问题。
TiDB enum 导致的性能问题：

enum 在 TiDB 3.0.2 进行 where 条件查找是，发现不能下推到 TiKV 。官方说4.0GA 修复。临时办法是修改到其他类型。
enum modify 为 tinyint 发现内容出现变化，原本的’'变成了 default 值， ‘1’ 变成了 2 ，经测试 varchar 正常，因此不要尝试去变更 DM 备份出来的 Schema 文件来实现表结构变更，应该从上游 MySQL 解决。

⑤分区表元数据无法获取
没有视图可以查询当前已建分区信息。在 TiDB 中目前没有视图支持查询分区表已建分区信息，那么用户那边没有办法直观的判断当前已建的分区，以及当前是否需要及时的添加新分区。目前已转化为 PRM 产品需求，相信新版本不旧会实现。
分区表 - 部分分区 - limit 未下推：分区表出现 limit 未下推的现象，表 content_info_p 其中只有分区 p201911 有数据。该问题已在 3.0.6 版本修复。
mysql.tidb 表权限异常：使用 use db_name 或者 mysql 客户端指定 DB name 后，可以对该表进行查询或更新操作。计划 3.1 版本修复。
事物的限制：单个事物的 SQL statement 不超过 5000（stmt-count-limit 参数可调）；每个键值对不超过 6M；键值对的总数不超过 300000；键值对的总大小不超过 100M 。
注：键值对是指一张表里有 2 个索引，那么一共就是数值 +2 个索引，总共 3 个键值对，那么每个键值对的总是不能超过 30 万/3=10 万。
一行数据会映射为一个 KV entry ，每多一个索引，也会增加一个 KV entry ，所以这个限制反映在 SQL 层面是：总的行数*(1+索引个数)<30w 。
官方提供内部 batch 的方法，来绕过大事务的限制，分别由三个参数来控制：

tidb_batch_insert
tidb_batch_delete
tidb_dml_batch_size

写热点的处理：如果可以去掉 MySQL 自增主键，就可以通过建表时指定 SHARD_ROW_ID_BITS、PRE_SPLIT_REGION 来实现预切分，避免单调自增引发的只往某个 KV 上写数据引起的热点问题。
详情可参考官网 TiDB 专用系统变量和语法中 SHARD_ROW_ID_BITS 的介绍。
⑥TiDB 监控和 DM 监控 Ansible 部署数据冲突
这块可以通过将 TiDB 和 DM 监控部署到不同的机器上来绕过解决，否则就会出现通过 Ansible 安装后， ansible-playbook rolling_update_monitor.yml --tags=prometheus 时，两者只有一个是正常的。
磁盘已使用不建议超过 50%：数据量太多 LSM 过大， compaction 成本会很高，并且内存命中率下降，同时单机恢复时间很长， 50% 左右最好，使用率太高，如果突然写入爆增， region 来不及调度会写满磁盘，有风险。
因此建议 SSD 不要使用超过 2T 的，采用更多的机器会有更好的性能。
⑦Mydumper 导致的内存和网卡打满
在使用 Mydumper 备份大时，会打满 TiDB 网卡，同时会消耗 TiDB、TiKV 更多的内存。

【TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】

去抓取慢日志会看到如下内容：

grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10'# Time: 2019-12-24T03:18:49.685904971+08:00# Txn_start_ts: 413433784152621060# User: backup@192.168.1.3# Conn_ID: 4803611# Query_time: 4002.295099802SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ;

期待后续的版本物理备份，逻辑备份看起来目前是可以备份，但会比较消耗资源，同时恢复时间也会更久。
展望从 TiDB 2.x 开始我们就已经开始进行测试了，最终选择的版本是 3.0.2 ，后续升级到 3.0.5 。
上述文章总结和一些案例希望能够帮助到已使用或打算使用 TiDB 的朋友。
360 云平台 DBA 团队也计划将 TiDB 推上 360 HULK 云平台，为 360 集团更多的业务线提供丰富多彩和稳定可靠的数据库服务。
在这里首先要感谢 PingCAP 同学及时的技术支持，帮助我们尽快的解决了一些技术问题。
同时，我自己也通读了 TiDB 的官方手册。从 Ansible 部署、二进制部署、升级、DM、Lighting、Pump、Drainer、调优、排障、迁移、备份，这一路打怪下来，切身感受到了 TiDB 越来越好的过程。