之前下过mysql现在重新下载mysql
tidb使⽤坑记录TiDB和Mysql的sql差异总结
tidb使⽤坑记录
1、对硬盘要求很⾼，没上SSD硬盘的不建议使⽤
2、不⽀持分区，删除数据是个⼤坑。
解决⽅案：set @@session.tidb_batch_delete=1;
3、插⼊数据太⼤也会报错
解决⽅案：set @@session.tidb_batch_insert=1;
4、删除表数据时不⽀持别名
delete from 表名 表别名 where 表别名.col = '1'  会报错
5、内存使⽤有问题，GO语⾔导致不知道回收机制什么时候运作。内存使⽤过多会导致TIDB当机（这点完全不像MYSQL）
测试情况是，32G内存，在10分钟后才回收⼀半。
6、数据写⼊的时候，tidb压⼒很⼤, tikv的CPU也占⽤很⾼
7、不⽀持GBK
8、不⽀持存储过程
9、列数⽀持太少，只⽀持100列，和oralce/mysql的1000列少太多（Oracle 最⼤列数为 1000；MySQL对于每个表具有4096个列的硬限制, 其中InnoDB每个表的限制为1017列, 最⼤⾏⼤⼩限制为65,535字节）
外⾯⽂章的⼀些建议
3TiKV＋3PD＋2TiDB
在有了 TiSpark 之后，我们便利⽤ TiSpark 将中间表缓存为 Spark 的内存表，只需要将最后的数据落地回 TiDB，再执⾏ Merge 操作即可，这样省掉了很多中间数据的落地，⼤⼤节省了很多脚本执⾏的时间
在查询速度解决之后，我们发现脚本中会有很多针对中间表 update 和 delete 的语句。⽬前 TiSpark 暂时不⽀持 update 和 delete 的操作（和 TiSpark 作者沟通，后续会考虑⽀持这两个操作），
我们便尝试了两种⽅案，⼀部分执⾏类似于 Hive，采⽤ insert into ⼀张新表的⽅式来解决；另外⼀部分，我们引⼊了 Spark 中的Snappydata 作为⼀部分内存表存储，
在 Snappydata 中进⾏ update 和 delete，以达到想要的⽬的。因为都是 Spark 的项⽬，因此在融合两个项⽬的时候还是⽐较轻松的。
最后，关于实时的调度⼯具，⽬前我们是和离线调度⼀起进⾏调度，这也带来了⼀些问题，每次脚本都会初始化⼀些 Spark 参数等，这也相当耗时。在未来，我们打算采⽤ Spark Streaming 作为调度⼯具，
每次执⾏完成之后记录时间戳，Spark Streaming 只需监控时间戳变化即可，能够避免多次初始化的耗时，通过 Spark 监控，我们也能够清楚的看到任务的延迟和⼀些状态，这⼀部分将在未来进⾏测试。
简介
根据⽹上⼀些使⽤案例列出⽬前TiDB和mysql在使⽤上的区别和⽬前的遇到的常见问题及解决⽅案，当然具体的使⽤问题还需要⼤量的线下测试才能确认。
问题类型问题描述原因及解决办法
DDL 在⼀个 DDL ⾥不能对多个列或者多个索引做操作。ADD/DROP INDEX/COLUMN 操作⽬前不⽀持同时创建或删除多个
索引或列，
需要拆分单独执⾏，官⽅表⽰ 3.0 版本有计划改进。
建表语句执⾏速度相⽐ MySQL 较慢
多台 TiDB 的时候，Owner 和接收 create table 语句的 TiDB Server
不在⼀台 Server 上时，
可能⽐ MySQL 慢⼀些，每次操作耗时在 0.5s 左右，官⽅表⽰会在后
续的版本中不断完善。
⼤表建索引时对业务有影响
官⽅建议在业务低峰期操作，在 2.1 版本中已经增加了操作优先级以及并发读的
控制，情况有改善。
TiDB 对于 MySQL ⽤户授权 SQL 语法的兼容⽀
持尚不完善，
⽬前不⽀持 SHOW CREATE USER 语法，
有时候不得不读取系统表（mysql.user）来查看
⼀个数据库账户的基本信息
希望后续版本优化
DML  部分操作符查询优化器⽀持不够好，⽐如 or 操作
符会使⽤ TableScan，
改写成 union all 可避免。
官⽅表⽰⽬前使⽤ or 操作符确实在执⾏计划上有可能不准确，
已经在改进计划中，后续 3.0 版本会有优化。
MySQL 事务中，可以通过影响条数，作为写⼊
（或修改）是否成功的依据；
⽽在 TiDB 中，这却是不可⾏的。
原因：
对于 MySQL，当更新某条记录时，会先获取该记录对应的⾏级锁（排
他锁），
获取成功则进⾏后续的事务操作，获取失败则阻塞等待。
对于 TiDB，使⽤ Percolator 事务模型：可以理解为乐观锁实现，事
务开启、
事务中都不会加锁，⽽是在提交时才加锁。
解决⽅案：
在业务层，可以借助分布式锁，实现串⾏化处理，但是会增加开发成
本。
对于热数据，数据量⼀般不⼤，但是查询频度很⾼，⽐
如查询 sql 为：
SELECT * FROM t_job_record where status=0
and execute_time<= 1546361579646
这个在 MySQL 中很⾼效的查询，在 TiDB 中虽
然也可从索引检索，
但其耗时却不尽⼈意（百万级数据量，耗时百毫
秒级）。
原因：在 TiDB 中，底层索引结构为 LSM-Tree。当从内存级的 C0 层
查询不到数据时，
会逐层扫描硬盘中各层；且 merge 操作为异步操作，索引数据更新会
存在⼀定的延迟，可能存在⽆效索引。
由于逐层扫描和异步 merge，使得查询效率较低。
解决⽅案：
尽可能缩⼩过滤范围，⽐如结合异步 job 获取记录频率，在保证不遗漏
数据的前提下，
合理设置 execute_time 筛选区间，例如 1 ⼩时，sql 改写为：
SELECT * FROM t_job_record where status=0 and execute_time>154635
7979646
and execute_time<= 1546361579646
select count(1) tidb查询慢
原因：和上⾯类似。
tidb因为存储结构和查询⽅式的不同，tidb其实是暴⼒扫表。很多使⽤
⽅也都反应慢，
这个是⽬前的TiDB的⼀个常见的问题。这⾥给出官⽅的解决⽅案：
增加、删除主键
⾮ UTF8 字符集
问题类型问题描述原因及解决办法
TiDB和Mysql优缺点对⽐
简单总结⼀下TiDB的优缺点：
TiDB优点
1. ⾼度兼容mysql协议，迁移成本低
2. ⾼可⽤：相⽐于传统主从（M-S）复制⽅案，基于 Raft 的多数派选举协议可以提供⾦融级的 100% 数据强⼀致性保证，且在不丢失
⼤多数副本的前提下，可以实现故障的⾃动恢复（auto-failover），⽆需⼈⼯介⼊。
3. ⽀持海量数据，可拓展性强：分布式数据库，可通过增加TiKV节点拓展，⽀持分裂和⾃动迁移，对业务基本⽆感知。
4. 和传统的分库分表，相⽐业务拓展性较强：传统的分库分表技术，开发和维护成本都较⾼，业务侵⼊性也较⼤，使⽤TiDB会明显降
低 RD 和 DBA 的开发维护成本。
5. 分布式事务
TiDB的不⾜
1. 对机器配置门槛要求较⾼，特别是内存和CPU的要求很⾼，当数据量不⼤时会增加机器的资源使⽤成本。
2. TiDB对sql的⽀持尚不完善，对⼀些sql的执⾏性能并不理想，⼀些复杂sql需要重新设计，还有⼀些mysql的功能并不⽀持。
3. TiDB技术较新，尚在不断优化中，因此也容易踩坑。
综合
综上所述，个⼈认为和mysql相⽐，
1. TiDB⽬前更适合TB级的海量数据处理，数据量越⼤，使⽤场景和优势越明显，
2. 也⽐较适合对查询性能要求不⾼的数据分析场景或离线计算场景
3. 即时场景下查询上最适合海量数据下进⾏多维度的精确查询
4. 整体⽽⾔TiDB技术仍不能算成熟，⽬前还在快速的更新和迭代过程中，容易采坑，建议引⼊也是先从离线业务->⾮核⼼业务->核⼼业
务的使⽤过程。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。