相同的数据库，TiDB集群服务器查询没有单机mysql查询快是什么原因？

[听风吹雨]

麻烦查看下 new_collations_enabled_on_first_bootstrap 参数值是不是设置为true了？

[rona]

对的，我们启用了这个参数

[rona]

大佬知道是什么原因导致的吗

[TiDBer_NtDbUm7p]

new_collations_enabled_on_first_bootstrap

• 用于开启新的 collation 支持
• 默认值：false
• 注意：该配置项只有在初次初始化集群时生效，初始化集群后，无法通过更改该配置项打开或关闭新的 collation 框架；4.0 版本之前的 TiDB 集群升级到 4.0 时，由于集群已经初始化过，该参数无论如何配置，都作为 false 处理。

跟这个参数应该没关系吧？

[chao (cc)]

提供下 TiDB 侧 explain analyze sql 的结果看看？TiDB 中非 coprocessor 部分还是会在单个 TiDB 节点上运算的，所以如果从 TiKV 取出的数据比较多，TiDB 侧还是有运算瓶颈的

[TiDBer_VHf8RBib (马克)]

@rona

SELECT
o. ,
od. ,
ue.is_email,
ue.is_liar,
IF(u.auth_phone != ‘’, 1, 0) AS is_phone,
ue.is_credentials,
p.product_name,
(
SELECT
v.email
FROM
tbl_pay_email_verify v
WHERE
v.email = od.pay_account
LIMIT
1
) AS auth_pay_account,
u.auth_phone AS phone,
ui.email AS email_ext,
ut.account AS promoter,
a. alias ,
od.origin_amount AS receive_point,
m.mdse_name,
odc.compensate_order_detail_id
FROM
tbl_order_detail AS od
LEFT JOIN tbl_order AS o ON o.id = od.order_id
LEFT JOIN tbl_order_promoter AS op ON op.id = od.detail_id
LEFT JOIN tbl_user AS u ON o.user_id = u.id
LEFT JOIN tbl_user_ext AS ue ON ue.user_id = u.id
LEFT JOIN tbl_user_info AS ui ON ui.user_id = u.id
LEFT JOIN tbl_user AS ut ON op.ad_uid = ut.id
LEFT JOIN tbl_product_web AS p ON p.id = od.product_id
AND p.site_id = od.site_id
LEFT JOIN tbl_product_alias AS a ON a.product_id = od.product_id
LEFT JOIN tbl_product_mdse AS pm ON pm.product_id = p.id
AND pm.site_id = p.site_id
LEFT JOIN tbl_mdse AS m ON m.id = pm.mdse_id
LEFT JOIN tbl_order_detail_compensate AS odc ON odc.order_detail_id = od.detail_id
WHERE
od.is_virtual = 1
AND od. create_time >= 1451577600
AND od. create_time <= 1644537600
AND (
p.product_name LIKE “%Football Manager 2017 Steam CD Key%”
OR a. alias LIKE “%Football Manager 2017 Steam CD Key%”
)
ORDER BY
od.create_time DESC
LIMIT
0, 15;

感觉mysql中关联表数据比tidb少？

[rona]

sql语句完全是一样的

[TiDBer_VHf8RBib (马克)]

TIDB 这边先做个analyze estrow 和 actrow 差距太大

[rona]

我现在需要怎么做？

[TiDBer_VHf8RBib (马克)]

https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-analyze-table#analyze

[TiDBer_4oMELAVl]

楼上说给个TiDB的执行计划

[rona]

TiDB执行计划tidb执行计划.txt (30.8 KB)

[rona]

tidb执行计划上传了，帮忙看看

[rona]

执行计划上传了，帮忙看看

[chao (cc)]

按照这个 plan 确实应该不会太快，每次 join 都会读出来大量的数据。

我试着导入 tbl_order.json tbl_order_detail.json 导入不进去。然后看了下里面的文件的 histogram 发现有很多不可见的特殊字符，这些字符是业务本身存进去的么。

比如

$ echo “AAl29GOli7+V7g==” | base64 -D
v�c�����%

[rona]

是tbl_order表吗
有个ip我们使用的varbinary类型的数据项，不知道是不是这个显示的乱码

[chao (cc)]

@chao

AAl29GOli7+V7g==

比如 ad_source 这一列。ip那一列应该没有影响

[rona]

@chao

业务本身存进去

ad_source数据项，正常是不会有乱码字符的，如果有零星的几条信息是由于字符集的原因引发的

[chao (cc)]

因为stats导入不进去，也没法本地调试。不过综合上面发的信息，还是因为join层数很多，而且每次join会有大量数据在tidb侧处理的原因导致性能不是很快。

[听风吹雨]

是否可以按照下面的方法导出一下文件：
https://docs.pingcap.com/zh/tidb/v5.3/sql-plan-replayer