你都能翻墙了..为什么不用电报 微信这玩应用过都知道是个啥逼样吧

@iosyyy #15 这样可以减少数据库缓存.. 对数据库见解比较浅 而且你这个需要具体问题具体分析 你给出的东西并不够多 建议补充下再说

@iosyyy 再补充一点 t2.create_time createTime,
t2.platform,
t2.id taskId,
t2.order_id orderId,
t1.business_contract_no businessContractNo,
t3.contract_no,
t4.contract_name
这些实际上都应该直接 select 1 这些数据我看你的逻辑应该是不需要查的

在这个查询中，表 t1 很大，而表 t2 、t3 和 t4 相对较小。为了优化查询性能，可以考虑以下几点：

索引优化：确保每个表上的相关列具有适当的索引。在表 t1 上，确保 business_contract_no 列上有索引，这将加速条件 t1.business_contract_no IS NOT NULL 的筛选。在其他表上，根据连接条件和筛选条件创建索引，以提高连接和过滤操作的效率。

重新排列连接顺序：根据表的大小和连接条件选择合适的连接顺序。将较小的表放在前面，以减少连接操作的数据量。在这个查询中，将 t2 表放在前面，t1 表放在后面可能更合适。

子查询优化：将子查询的结果存储到一个临时表中，并在最外层的 SELECT 语句中使用该临时表。这样可以避免在子查询中重复执行相同的操作，提高查询效率。

下面是优化后的查询代码：

sql
Copy code
-- 创建临时表存储子查询结果
```sql
CREATE TEMPORARY TABLE temp_result
SELECT
t2.create_time createTime,
t2.platform,
t2.id taskId,
t2.order_id orderId,
t1.business_contract_no businessContractNo,
t3.contract_no,
t4.contract_name
FROM
esign_task_item t1
INNER JOIN esign_task t2 ON t1.task_id = t2.id
LEFT JOIN esign_contract t3 ON t3.task_item_id = t1.id
LEFT JOIN esign_contract_template t4 ON t4.contract_no = t1.contract_template_no
WHERE
t1.business_contract_no IS NOT NULL
GROUP BY
t1.business_contract_no,
t2.order_id,
t2.id
ORDER BY
t1.id DESC;
```

-- 查询临时表中的行数
SELECT COUNT(*) FROM temp_result;
请注意，根据实际情况，你可能需要调整索引、连接顺序和其他查询优化技术来进一步提升性能。这些优化建议提供了一般性的指导，具体的优化策略应根据数据库引擎和数据量等因素进行调整。

chatgpt 生成的我输入的条件就是 t1 是大表其他都是小表相连 如果其他也都是大表我建议你更改数据库结构减少笛卡尔积
另外这里的
```sql
GROUP BY
t1.business_contract_no,
t2.order_id,
t2.id
```
应该被删除掉

consolas 苹方 等等

@Yunen 太残疾了

create_time order_status status 建立联合索引 (user_id 如果是主机键就不用 速度就提上来了

ICPC ACM 等等

@finab #100 经验丰富的程序员会做枚举... 就不会这么判断来做

这种一般是按照手机信号 你手机上有百度地图并且路过该地段那百度地图可以把它记录下来 所以最好的办法是用百度的 api https://lbsyun.baidu.com/products/traffic

对于 innodb 来说他的数据和 id 是存在一起的 btree 底层具有排序信息所以不需要额外对 id 排序 也就是不需要走 filesort

@AllNewDesign #62 经典查成分..这种页面不是太多了

@unknowsun #50 要我说你对象可能也不一定怎么尊重你 可能也是旁观者清吧

在用 Arc 浏览器 默认就是垂直标签 很不错