虽然没啥问题 可是现在这个大环境 优秀毕业生都用不完了 为了效率 简历筛选 HR 只能简单粗暴的把类似这种直接筛掉了 除非在其他方面有亮点

怀疑是我同事发的 https://i.imgur.com/io2SM1h.png

现在挺多云平台都支持的

看简历 属于是 2 年经验中比较强的了 可惜空档期很难过简历了

@spikeLee #2 实习一般不算做工作经验 按毕业时间算的

小新 Pro 14 2023 旗舰锐龙版 马上要发了 做工挺好的 CPU 、屏幕也强

过分理性、逻辑，容易钻牛角尖

坐标杭州 今年 3 4 月份换房子的时候 房租普遍降了

oh-my-posh utools ditto MagicPods

如果 run 了 这些钱可以退不 有懂哥知道不

@tangds99 #9 老人们 不是有软肋吗 https://i.imgur.com/io2SM1h.png

执行力 MAX

并没有 感觉北京 上海 深圳还是机会比其他地方多

有书面 offer 的话 可以仲裁不

算法时间不够吧 这个要日积月累的 当然 大佬的话 当我没说

东大方 老头油爆虾 价格实惠 有江浙菜特色

从大一开始刷题

优化建议如下：

1. 索引优化：为表 esign_task_item 的列 business_contract_no 创建索引，以加快 WHERE 子句中的条件判断。

2. 子查询优化：将子查询中的 GROUP BY 子句中的 t2.order_id 和 t2.id 移至外层查询中，以避免在子查询中进行分组操作。

3. 子查询优化：将子查询中的 ORDER BY 子句中的 t1.id 改为 t2.id ，以避免在子查询中进行排序操作。

优化后的 SQL 如下：

SELECT
COUNT(*)
FROM
(
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.id,
t2.order_id
ORDER BY
t2.id DESC
) TOTAL