【慢Sql，耗时≈5s】

在Archery平台发现近期的一个慢sql：SELECT * FROM emax_order_detail WHERE import_order_no = ?

 经测试，的确是慢。SELECT * FROM emax_order_detail WHERE import_order_no = '1738120234847571968' 。尝试加上limit 1，依然超过5s。

​

【如何优化】

优化方式，直接的方式是在 import_order_no 上加索引。这也是头疼医头的方式。

有没有注意，emax_order_detail 已经有许多索引了。

 【发现问题就解决，往往是低效的方式】

我们对业务进行分析，程序稍作改动，下面sql执行性能提高数倍。

SELECT * FROM emax_order_detail WHERE create_time>='2023-12-17' and import_order_no = '1738120234847571968'

SELECT * FROM emax_order_detail WHERE enterprise_id=1700039047700220 and import_order_no = '1738120234847571968'

【一言以蔽之，企业开发中，理清业务，事半功倍，包括所执行的sql】

类似的慢sql有许多，

• 定时任务 按进行中状态拿一批数据的sql

• 三方通道回调，假定三方给的报文里只有三方自己的单号，按三方单号定位数据记录的sql

• 三方通道回调，三方给的报文里包含我司单号、三方自己的单号，程序却直接用三方单号定位数据记录

• 企业协议列表上的“查看保全合同”操作，传给auth的不是协议id，而是三方的合同编号。auth本可以通过协议id定位记录，却要通过三方的合同编号定位记录。

• 企业开票记录里，保存的服务商发票类目id是服务商系统返回的id。查询发票类目名称时，传给channel的是服务商返回的发票类目id。channel本可以用自己的主键定位记录，结果却用服务商返回的发票类目id定位记录。

• 我司提供给商户的查询交易回单的API，商户上送商户自己的订单号，我们程序直接根据商户单号定位记录。（本案）

• 。。。

只要对业务稍加分析，我们程序就不会出现这么多慢sql。