发现sql慢就加索引？非也！

【慢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'

 

【一言以蔽之，日常开发中，要重视可能产生的性能问题】

企业应用系统中，绝大多数业务场景并不复杂，例如基础数据CRUD、数据业务配置、定时任务、数据接口暴露以及消息传输等。凭借掌握的技术和经验，许多开发同学都可以搞定。不过，如果单纯任务的完成，而忽视了其他一些更重要的因素，那么我们只能说勉强完成了工作，而无法称之为靠谱和优秀。

以本案主题为例，emax_order_detail订单详情表存量数据和增量数据都很大，并具有高频操作的特征。在编写对这个交易表的业务代码时，我们（jué）不能简单地满足业务需求，而应该关注程序的性能，注意到可能出现的性能问题。这时，就要求我们对业务、对数据和数据结构多加思考和分析。如此这般，我们编写的代码才能避免类似慢 SQL 的出现。

在我们的系统中，类似的慢sql有许多，值得我们留意。-->思考一下，应该怎么做性能优化？

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

• 定时任务-关闭已过期订单，按过期时间更新订单状态的sql

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

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

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

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

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

• 。。。

 

 

BTW，除了完成基本的工作任务，还应考虑哪些因素？↓