无

学无止境 发表于 2023-12-29 09:35
1、配置基本上一样；
2、反复测试了10几次，都是一样；
3、GreatSQL用的是最新版本8.0.32-25 ...

方便提供表ddl和测试数据吗，我自己也尝试看看。


另外，还有两个观察的方法，请再尝试下：
1、分别执行EXPLAIN ANALYZE SELECT ... 查看实际执行过程中的代价和耗时
2、利用profiling查看瓶颈，大概方法如下

1. greatsql> set profiling=1;
   
2. greatsql> select ...; -- 执行SQL
   
3. greatsql> show profiles; -- 查看刚才执行的那条SQL对应的query id，比如是N
   
4. greatsql> show profile for query N; -- 查看刚才执行SQL各阶段耗时

复制代码

yejr 发表于 2023-12-29 13:36
方便提供表ddl和测试数据吗，我自己也尝试看看。

抱歉这里面的数据是再用的，不太好发过来，可以远程操作查看；
sql：
EXPLAIN ANALYZE  SELECT COUNT(*) FROM(select  a.Acc_authorize ,a.Acc_SF_FirstName ,a.Acct_Cust_Name ,a.ID,a.Acc_ISTopCustomer,a.Acc_IsVip,a.Acc_AccountName,a.Acc_CustomerName,a.Acc_AccountID,a.Acc_ALevel,a.Acc_BLevel,b.Sys_DeptName,a.Acc_CompanyID  from work_account a left  join sys_dept b on a.Acc_CompanyID=b.Sys_DeptID  and b.Sys_DeptLevel=2 where 1=1   ) as t;

greatsql：
| -> Aggregate: count(0)  (cost=2689843.84 rows=1) (actual time=18842.025..18842.025 rows=1 loops=1)
    -> Nested loop left join  (cost=2208423.44 rows=4814204) (actual time=0.097..18277.875 rows=4914510 loops=1)
        -> Covering index scan on a using index_companyID  (cost=523452.04 rows=4814204) (actual time=0.083..1353.213 rows=4914510 loops=1)
        -> Filter: (b.Sys_DeptLevel = 2)  (cost=0.25 rows=1) (actual time=0.003..0.003 rows=0 loops=4914510)
            -> Single-row index lookup on b using PRIMARY (Sys_DeptID=a.Acc_CompanyID)  (cost=0.25 rows=1) (actual time=0.003..0.003 rows=0 loops=4914510)

Mysql：
| -> Aggregate: count(0)  (cost=2.39e+6 rows=1) (actual time=2287..2287 rows=1 loops=1)
    -> Nested loop left join  (cost=1.96e+6 rows=4.32e+6) (actual time=0.104..2107 rows=4.92e+6 loops=1)
        -> Covering index scan on a using index_companyID  (cost=451138 rows=4.32e+6) (actual time=0.0798..912 rows=4.92e+6 loops=1)
        -> Filter: (b.Sys_DeptLevel = 2)  (cost=0.25 rows=1) (actual time=142e-6..153e-6 rows=0.201 loops=4.92e+6)
            -> Single-row index lookup on b using PRIMARY (Sys_DeptID=a.Acc_CompanyID)  (cost=0.25 rows=1) (actual time=65.8e-6..69.3e-6 rows=0.201 loops=4.92e+6)

学无止境 发表于 2023-12-29 14:18
抱歉这里面的数据是再用的，不太好发过来，可以远程操作查看；
sql：
EXPLAIN ANALYZE  SELECT COUNT(*)  ...

执行计划看起来基本一样，怀疑是系统或硬件层的因素导致的，请检查数据库配置参数，以及CPU、内存、磁盘I/O方面的配置&性能是否一致，例如可以先用sysbench做的简单的fileio及oltp测试对比。

咋把标题和内容都清空了？

yejr 发表于 2023-12-31 09:32
执行计划看起来基本一样，怀疑是系统或硬件层的因素导致的，请检查数据库配置参数，以及CPU、内存、磁盘I ...

硬件应该一致，不存在问题，我把greatsql卸载了，在这台服务器上面部署了mysql8.0.35，同样的数据去执行，只需要1秒多；测试了很多次；都是1秒多；不止跑这条语句，跑其它的语句都比较慢，我这边还有好几条sql，在mysql上面需要135多秒，在greatsql上面需要200多秒；

yejr 发表于 2024-1-2 09:19
咋把标题和内容都清空了？

非常感谢帮忙排查，我这边感觉这个查询差距非常大，进行了多次重新安装或者换服务器，效果还是依旧；可能是我这边部署的原因或者其它原因，部署参考的是文档，估计还有一些细节是我没有注意到的；当前准备先停止greatsql测试；再次感谢

学无止境 发表于 2024-1-2 09:45
非常感谢帮忙排查，我这边感觉这个查询差距非常大，进行了多次重新安装或者换服务器，效果还是依旧；可能 ...

有点遗憾，希望以后有机会再来测试GreatSQL，感谢。