为什么我们要从MySQL迁移到TiDB？

调优完成后是有提升，但提升不大，我们得知新版本的 TiDB 在 Load data 这块又有速度提升，比较期待新版本。

其他干货打包分享

①TiDB 列数超限

MySQL 是 1024，TiDB 目前限制是 512 列。如果你的表有非常多的列，那么这块要提前注意下是不是可以拆分出去。

②GC can not work

GC 的数据包括两部分，一部分是 DML 和 DDL ，DDL 的 GC 的对象信息包含在 mysql.gc_delete_range 和 mysql.gc_delete_range_done ，分别记录的是待 GC 的对象以及已经 GC 的对象。mysql.gc_delete_range_done表里面没有数据不代表 GC 异常。

官方建议更换规则：

sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d])) 

③TiDB or 条件优化

在 TiDB 中，如下查询是不能用到索引的

select * from manual_domain where host_md5  = '55fbea39965484a61xxxxxxxxxx'  or domain_md5 = '55fbea39965484a61xxxxxxxxxx'; 

MySQL 中用到了 index_merge，TiDB 计划 4.0 支持，可以先用 union all 来处理这种 a or b。

④Coprocessor CPU 消耗过大

业务反馈查询变慢，发现是另外一个业务全表扫 insert into select 导数据导致的。

去 CPU 占用率高的这台机器上搜索对应的 log，关键字 slow，发现如下情况：

[2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437] 

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

TiDB enum 导致的性能问题：

enum 在 TiDB 3.0.2 进行 where 条件查找是，发现不能下推到 TiKV。官方说4.0GA 修复。临时办法是修改到其他类型。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!