用 clash

@gddg 我这边是 5gb 左右 不跑服务的情况下

@chuck1in 这些还好吧... 大多数人可能都会写点 但应该不算精

@zlhsvc 唉, 美国

@iosyyy chatgpt

在这两种对齐方式中，第一种方式（方式 1 ）通常比第二种方式（方式 2 ）更受推荐，原因如下：

可读性：第一种方式允许变量名的长度自然变化，使得代码更易读和理解。当变量名长度不一致时，对齐会导致外观上不够整齐，但通常更直观和美观。

代码规范：第一种方式符合 PEP 8 代码风格指南，这是 Python 代码的官方风格指南。PEP 8 建议避免在赋值等号（在这种情况下）之前使用多个空格。虽然第二种方式尝试通过 # noqa 来忽略代码检查警告，但最好在可能的情况下避免与代码规范冲突。

可维护性：如果未来添加或修改变量，第一种方式会自动适应变化，而第二种方式可能需要手动调整对齐，如果不仔细处理可能引入错误。

一致性：第一种方式更符合典型的 Python 代码风格，遵循大多数 Python 项目中使用的标准缩进做法。

总体而言，通常更应该优先考虑可读性、可维护性和代码规范，而不是严格的对齐。第一种方式允许灵活处理变量名长度，同时提供更干净、符合标准的代码风格。

chatgpt

在 InnoDB 引擎下，你可以通过使用自增主键和外键来实现类似的目标数据库形式，尽管不能直接设置联合主键并让 subId 自动增长。以下是一种可能的方式来实现该结构：

创建主表（ id 主键自增）：
sql
Copy code
CREATE TABLE main_table (
id INT AUTO_INCREMENT PRIMARY KEY
);
创建子表（ subId 主键自增，同时包含 id 的外键约束）：
sql
Copy code
CREATE TABLE sub_table (
subId INT AUTO_INCREMENT PRIMARY KEY,
id INT,
FOREIGN KEY (id) REFERENCES main_table(id) ON DELETE CASCADE ON UPDATE CASCADE
);
插入数据：
首先，插入主表数据：

sql
Copy code
INSERT INTO main_table VALUES (1), (2);
然后，插入子表数据（ subId 会自动增长，而 id 将来自于主表的 id ）：

sql
Copy code
INSERT INTO sub_table (id) VALUES (1), (1), (1), (2), (2), (2), (1);
这样，你可以在 InnoDB 引擎下建立主表和子表，并通过外键将它们关联起来。虽然 subId 并不会像 MyISAM 引擎中设置联合主键那样自动增长，但通过使用自增主键和外键，你可以实现类似的目标数据库形式。


不过我的建议是这种操作最好不要放到数据库直接查一下不就完事了..这东西有索引而且是数字定位很快的

应该可以考虑 AST 吧..

看眼睛是礼貌..哪怕不一直盯着看呢 别人和你对话的话他目光涣散你很容易发现的

感觉没啥太好的办法..
不过就这个感觉可以取样假设有 1000 台随机分片出来的 client 拿到的数据一致就默认他一致 或者用消息队列也可 就是你把这些 hash 后的或者 md5 的数据都上传到消息队列统一处理🤔

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

@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 太残疾了