在mysql能查出来，在tidb查询，tidb直接崩溃重启，是什么原因？

[Kongdom]

这边建议如果只有一台服务器的话，使用单节点部署，1TiDB+1PD+1TiKV就可以了。即使这样，盲猜性能应该也不如mysql，毕竟使用场景不同，汽车再好也得配个发动机，配个毛驴拉车始终是不行的。

[TIDB-Learner]

重复下题主的场景在一台主机上 安装了tidb和mysql，两者做了数据同步，同样的数据量。测试效果 tidb不如mysql。导致的原因可能如下：
1.tidb没有建索引导致。或者有组合索引-且在mysql和tidb一样的配置，需要解析下，tidb的组合索引是否生效，或者拆分下。
2.列存和行存数据 在同一盘下。这是十分影响性能的。即便混合部署，建议分在不同的盘下。
3.如果使用了临时表，内存达到上限。优化内存配置参数

[Jellybean (李文杰)]

TiDB是一个分布式数据库，如果是功能验证和简单测试，可以使用单机部署。

但是如果要进行性能测试，或者正式生产使用，需要保障一定的硬件基础设施。

简单来说，一句话，你的表行数在5000万行以下，单机部署、未来没有更大数据量的增长和性能增长，用mysql 是更好的选择。

如果你的表是更大的情况，1亿行、10亿行、100亿行以上，未来有性能和数据量的增长势头，还要保证毫秒级别的TP 响应，选择TiDB吧。

所以，结论是你的性能验证方式需要在合适的环境下验证才行

[czxin788]

我发现tidb的索引统计信息里面的Cardinality是不是不准导致的：
tidb w表索引信息：

mysql w表索引信息：

[czxin788]

我已经将数据库版本从v7.3.0升级到7.5.0。
并重新全量同步了一次数据，对于这个sql，tidb还是走了全表扫描，索引信息见上面的截图。
两边表结构一样。

[托马斯滑板鞋]

@czxin788

Cardinality

BUG？

[托马斯滑板鞋]

再试着手动收集个全量统计信息，看看这张表的 STATISTICS 信息更新不
ANALYZE TABLE w WITH 1 SAMPLERATE;

[czxin788]

你意思是tidb未使用CARDINALITY字段，不用关注是吧。
那我这个sql不知道为什么用全表扫描。tidb根本执行不出来这个sql。mysql 20多秒能出结果。

[托马斯滑板鞋]

我的意思是，Cardinality 那列的值应该全部是0，而不应该有值出现

[托马斯滑板鞋]

这几张表是单独导出来再导入的，还是你把整个mysql库给导过来了？

[czxin788]

我只导了业务库，备份时是加-B指定库的
没有导mysql库、sys库等系统库。

我现在在执行ANALYZE TABLE w WITH 1 SAMPLERATE;命令，非常慢。
等执行完了，我再贴一下结果。

[czxin788]

执行这个命令，ANALYZE TABLE w WITH 1 SAMPLERATE;
等待了5分钟左右，tidb竟然重启了

[托马斯滑板鞋]

有tidb.log 和 tikv.log吗？看看重启原因

[路在何chu (Ti D Ber Ass Gn Qs R)]

应该是统计信息不准，你删除统计信息，在收集一下，试试

[czxin788]

czx_tidb.log (7.4 MB)
czx_tikv.log (634.9 KB)

日志见附件。
重启时间大概是13:50左右

[czxin788]

怎么删除统计信息

[托马斯滑板鞋]

DROP STATS TableName;
https://docs.pingcap.com/zh/tidb/stable/statistics

[路在何chu (Ti D Ber Ass Gn Qs R)]

drop table xx stats;

[路在何chu (Ti D Ber Ass Gn Qs R)]

这日志看不出啥，就启动信息，系统日志发出来看看

[托马斯滑板鞋]

tikv日志从14:06开始的，不过盲猜是OOM，重新收集统计信息吧
如果100%过不去就降低比例
ANALYZE TABLE w WITH 0.3 SAMPLERATE;