【 TiDB 使用环境】测试
【 TiDB 版本】 v7.3
【复现路径】
【遇到的问题：问题现象及影响】
我们有个超级复杂的sql，在mysql里面20s出结果，放在tidb里面查询，等待了大概5分钟后，tidb直接崩溃自动重启了，请问一般是什么原因。
【资源配置】
如果混合部署的话，做下资源隔离，开启 tidb-server 的结果落盘。
可以加几台机器试试 tiflash。
1 个赞
tidb oom了,sql 执行计划贴一贴
发一下tidb的集群拓扑以及资源配置
把集群的配置资源部署情况，拓扑
sql的执行计划
oom的信息日志信息附加上。才能分析具体是什么原因
tidb什么硬件配置
需要监控，日志进一步分析
mysql执行计划.txt (23.5 KB)
tidb执行计划.txt (241.8 KB)
执行计划见附件。
机器配置为：256G内存，64 cpu。
tidb和mysql在同一台机器上，tidb和这个mysql保持数据同步。
tidb是在一个机器上部署的伪集群，目的是测试tidb的性能是不是真的比mysql好。
实际情况不完全是，有的sql在tidb执行快很多，有的在tidb变慢了，甚至执行不出来。就比如附件这个，竟然能直接把tidb干重启。
啥意思？
mysql和tidb在同一台物理机上面？
tidb怎么部署的？不同端口三个tikv？还是 1pd 1tikv 1tidb这样？
两边表结构一样吗？
tidb里全表扫描
TableFullScan_1907 | 26477481.00 | cop[tikv] | table:m
TableFullScan_1910 | 1147772.00 | cop[tikv] | table:w
MySQL里主键？
| 1 | PRIMARY | m | NULL | ref | idx_NumericalOrder,idx_NumericalOrder_PigID,idx_NumericalOrder_BatchID_PigID,idx_NumericalOrder_PigHouseUnitID_PigID,idx_NumericalOrderDetail_IsIn,idx_NumericalOrder_IsIn_Abstract | idx_NumericalOrderDetail_IsIn | 8 | zhongguo_qla_business.w.NumericalOrderDetail | 1 | 100.00 | Using index condition; Using where |
| 1 | PRIMARY | w | NULL | ref | wm_warehousestockpigextend_NumericalOrderDetail_index,idx_Guid | idx_Guid | 108 | zhongguo_qla_business.s.Guid | 1 | 100.00 | NULL |
tidb集群display看一下。
看来TiDB复杂SQL得加强啊。MySQl是C++写的吧。TiDB不会是Java写的吧。
go写的
1、建议用7.5版本（7.3是DMR）
2、如果是单机，建议1TiDB 1PD 1TIKV就够了
3、表结构是一样的吗？怎么一边走主键，另一边很多全表
如果在tidb中sql走的索引与在mysql中不同，可以在SQL中加hint重新执行下试试
有道理啊，两个不同数据库中表的索引和主外键设置是否一致。这个很关键的。
查一下index和Foreign Key
两边表建的一样吗，一边是都是全扫啊，一边还好