感觉tidb应该在开启参数情况下，自动检测一下系统配置的合理性。

估计这个表不涉及中文字符问题。没必要用mb4

简单的时间对比不好分析原因，最好的办法还是分析执行计划。 jion效率低往往几方面： 1，一般的建议是join表不要超过3个。 2，驱动表很重要，执行计划驱动表有没有搞对。 3，join可以走索引的，关联字段加索引能有效加速。不走可能因为没建或者统计数据不对。

like如果走索引，只会走左匹配。 最好把create 语句导出来一下，才能综合评价如何优化。

选3。PD不需要对tidb server的负荷做负载均衡，所以知道tidb server的并发度没用。

这里我给tidb提一点建议，一般大公司对数据库驱动都有严格的介质管理，不是你说换驱动就换。 所以，通过换驱动来解决问题是一个方法，但是不是好的实践。 如果想生意做大，我建议还是作为bug fix来修复。

81有tiproxy 这是个好东西，以前的用负载均衡是不带会话数据共享的，也就是说如果其中一个tidb server挂了，你原来的会话转移过去其他tidb server也没用，因为session信息丢失了。tiproxy好像可以共享会话信息。

问题1：96M参数可以调整，这个是region分裂的参数。一个表的region是可以手工设置，但是如果数量不足，可能设置后还会被合并，当然也有参数可以抑制系统自动合并。 第二个问题：实测，可以多个表，而且表数据和索引数据混合存储。 第三个问题：因为生产环境往往比测试环境配置高。简单说就是tikv的数量多，为了增强并发能力，PD会自动打散表数据到多个region，另外，生产环境可能replica数量也会多一些，看你们设置。测试环境机器配置差，有的甚至是单机，当然只能减少region了。 以上这些问题都清晰了吗

原因上面的朋友已经说了，如果想在dashboard排除这些，可选择database和添加查询条件。

我没做过运维，不过老哥。你图里的磁盘性能有点差。 PCIE 3.0 x4的磁盘读3500M/S，4.0X4可以达到7000M/s。PCIE 5.0就更加快了。 tidb就是利用NVME盘的这种高IO来设计的，确实可以把mysql摁在地上摩擦的。 要是换成HDD，只能说，违背了tidb的设计初衷了。

日志感觉挺清晰了。因为端口被占用了，netstat -nltp | grep 端口 查看是哪个进程占用了端口，我没玩过docker，单机通常都是存在其他进程占用，看看没用就kill掉，不行就换端口。

公司有个专门的部门去研究数据库，提供参数模板

公司如果经费足，肯定用企业版呀。毕竟除了什么问题有一堆高手给你兜住。 福出者福来，爱出者爱返。有机会有条件，还是得多关照一下开源企业和开源兄弟。

在日本 tidb已经是数据库排名第一的数据库。并且是连续三年排名第一。 虽然这句话无从证实，但是也给你点赞。

是不是因为dashboard走grafana的数据。show stats_meta where table_name like 'xxx’走的应该是数据库的统计数据。结果不一样，说明grafana是不是有问题？

explain analyze 查看执行计划，跟原来postgresql的执行计划对比一下，就知道问题在哪里了。很多时候dba为了省事，配置tidb不自动进行统计信息采集，也可能会带来问题。你可以看看表统计信息是否采集了。

最佳答案都选好了，我也认同。 另外提醒一下要考虑truncate时候，1，这个表是否有高频的修改和删除，可能会影响truncate的执行。2，是否存在ddl队列排队。

这个问题有点笼统了。看使用场景吧。tidb主打的是一个newSQL，性能能够根据需求扩展。 mysql好处是稳定，但是通常开始就要做好性能需求分析，选择好合适的机器，mysq估计装在power上面性能还是很强劲的，但问题是贵呀。 在目前讲求经济性，讲求x86下移的大趋势下，tidb以后应该会比mysql更有想象空间，更符合性能可以弹性拓展的大趋势。

如果是我，我估计会先升级从节点，毕竟从节点影响比主节点小很多。有什么问题都能够从主节点重新恢复。当然如果官方有指引，当我没说。