为什么我们要从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 修复。姑且步伐是修改到其他范例。

（编辑：湖南网）

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