今天下午接到的消息，项目要推迟了，原因是部门的产品的revenue远低于预期，sales说产品质量太差，很难卖，作为开发人员，我们确实也感觉到产品的质量并不是很好，性能存在较大问题，所以开发部门也没有很大的底气反驳这个说法，在我们之前，他们原来都没有做什么像样的性能测试，后来的性能测试的压力也远远小于实际客户的压力，而我们要做的产品，压力是目前最大客户的2倍以上，我们在做我们自己的性能测试的时候已经发现了很多性能问题。
调整的结果是我们的产品推迟（毕竟在沙地上盖房子不会有什么好结果），但是我们去做什么还不太确定，大原则是帮助他们提高他们的产品质量（他们现在深陷火坑，一堆的bug等待他们去解决，没有额外的资源去做产品的提升，而且可能面临裁员），但是怎么合作是个大问题，具体做那些东西也很难讲，真正核心的东西肯定不会给我们做，老板估计也不敢给我们做，但是做其它不痛不痒的东西我们也没有什么成就感，纯粹的变成帮忙扑火了，如果他们自己不能把大问题解决好，我们最后也不会有什么好结果，唉。
我们有张表是存储用户自定义的类似tag的信息的，有一个功能是按照tag进行搜索，而且支持搜索多个tag查找同时使用这些tag的对象，最开始的实现就是使用的intersect，我感觉可能有问题，然后正好没有太多的事情，就试了下性能，发现那个SQL可以进行改造，变成group by 加 having的模式，一个查询搞定，弄了大概4万条数据，两个SQL（同时查4个Tag）的对比结果显示，前面的SQL会扫描整个表4次（和查询的tag的次数直接相关），并且有一次写入操作，而后面的只有一次扫描没有写入操作，时间上后面的SQL的性能是前者的两倍以上。所以对于同质的SQL的intersect可以转换为这样的group by加having的模式。
原来的SQL:
select ObjectID from ConfigObjectMetaData where KeyNameHash = -3023837279545376792 and ValueStrHash = -6420380264491338705 and ObjectType = 10
intersect select ObjectID from ConfigObjectMetaData where KeyNameHash = 6769857814803370866 and ValueInt32 = 2 and ObjectType = 10
intersect select ObjectID from ConfigObjectMetaData where KeyNameHash = 3984357063977881949 and ValueInt32 = 3 and ObjectType = 10
intersect select ObjectID from ConfigObjectMetaData where KeyNameHash = -3087541436254450506 and ValueStrHash = -3706752959682952160 and ObjectType = 10
修改后的：
select ObjectID from ConfigObjectMetaData where ObjectType = 10 and (
(KeyNameHash = -3023837279545376792 and ValueStrHash = -6420380264491338705)
or
(KeyNameHash = 6769857814803370866 and ValueInt32 = 2)
or
(KeyNameHash = 3984357063977881949 and ValueInt32 = 3)
or
(KeyNameHash = -3087541436254450506 and ValueStrHash = -3706752959682952160)
)
group by ObjectID
having count(ObjectID)=4
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑