首先对两大善佬道谢
oaifree 对o1的跟进情况 - 运营反馈 - LINUX DO
免费Claude Pro，官网镜像！ - 资源荟萃 / 资源荟萃, Lv1 - LINUX DO
因为不知道必须截图所以必须用自己电脑重新编辑了，顺便感谢写免费Claude Pro，官网镜像！ - 资源荟萃 / 资源荟萃, Lv1 - LINUX DO油猴脚本的大佬，要不然我连Claude也要重新搞了，，
真的很倒霉，我写的时候电脑突然死机，重启之后始皇的o1就被刷掉了。。。。。幸好提前复制了
说在前面：公司不方便截图，所以只有文字描述，见谅:)
背景：有一个站内信大表，700W数据，其中有一个权限很大的用户，他自己有20w的站内信，需要查询用户的未读条数。
相同的问法：给出数据库DDL，查询语句，问如何优化这个慢查询。
o1：（我用的中文问的，但是给的回答是英文）
换自己的电脑是真的找不到历史记录了。。现在用的是文字生成的图
Claude3.5 Sonnet给出的方案：（直接就是中文）
我认为从改造的难易程度和设计来说，最好的方法是Claude3.5 Sonnet（下文以3.5代替）给出的维护计数表，这也是我最开始所设想的方案（非自夸，如果大佬们有更好的建议，欢迎交流）
可以看出，o1和3.5都有很多的不必要建议，比如对索引的改造，玩一些不必要的优化如count（*）之类的，感觉都有点凑数必须给多条建议一样（）
我认为有意义的分别是
分区
o1给出的分区是正确的，把receive_id放到了主键里面（忽略DBA的尖叫）
3.5给出的分区没有做主键的更新，经过提醒之后正确给出了主键更新
缓存
o1，但是这个加缓存没用，因为只要查询必然慢，不是因为查的频率问题
维护计数表
3.5给出了合理的设计
o1我提醒它之后，它给出了把未读条数一条条的add到新表里面，再来统计数量。。再次提醒它可以直接写未读数量，它就把全部的代码（包括未读消息产生时需要count+1）的都给出了。
说下结论：经过这一周左右的体验，我觉得就业务理解来说，3.5比o1强一丢丢，如果是纯代码类的优化，比如秒杀页面的聚合，o1就能一遍过，如果佬友们感兴趣，那我发个新帖分享一下
如果佬友们对这个实在感兴趣，那我把敏感信息都删除，把全部的提问都分享出来，大家一起研究
不可以傲慢。这是本论坛的氛围基调，哪怕你技术再牛，我们也不欢迎傲慢。