新入职家公司,规矩好多。。

为了保住工作,各种psr标准按照要求改了好多了,但今天属实有点蚌埠住了,起因是之前写的一个项目,表关联太多了,查询慢了(小项目,主要当时写的快,忘记优化sql了),关键那个查询关联和分组情况比较复杂,还有分页,最终也还是只通过优化sql解决(优化之前查询0.4秒,优化后0.03秒左右),然后就又加了新的代码需求,不能联表查,不能子查询,如必要,必须要向上申请,我回去查看了下之前几个项目,基本上70%的select 都是有join的。。。。

各位所在的公司对sql的限制是怎样的呢?我个人是这么想的 join表多了确实难优化,但限定2张表感觉也就ok了把,直接限定不能联表的话感觉有点难受啊。。。。

讨论数量: 19
php炎黄

看多少人用吧,像我司都是查缓存

1年前 评论

这么严格的吗。。

1年前 评论
poker_face (楼主) 1年前
邢闯洋 (作者) 1年前
你看我吊吗啊

@小李世界 sleep(79) ?

1年前 评论
pndx

我这里是要求都改成多条语句来查询,看结果是快了挺多了,就是麻烦了点。

1年前 评论
poker_face (楼主) 1年前
清风 11个月前
pndx (作者) 11个月前
bishi123 2周前

我公司也是这样,建议用单表不建议联表。不过要是会用联表(理解联表的优化)也不会阻止。可能是对于我们这些没有处理过大数据的程序员 如果滥用子查询,联表对于后期的不太好维护。而且单表查询再通过PHP进行处理,性能也不会很差。

1年前 评论

一般我们都是限制三张表关联查询。

11个月前 评论
她来听我的演唱会 11个月前

惊呆了老铁 :see_no_evil:

8个月前 评论

我怼,我司老项目直接 7 8 张表联查起步

8个月前 评论

关联模型查询也不行吗

7个月前 评论

联表查,特别是多表的情况下,没有优化,没有加索引(还要考虑命中的问题),一旦数据量大的化,是很容易慢得要死的,所以为了不要后期再优化,单表查是最快的,哪怕你的业务量多需要很多表,单表也是最快的,前提是数据量大,数据量小无所谓了!!!其实这也是一种提升,很好的

2周前 评论

应该把复杂的业务查找交给语言本身,数据库不应该写复杂联表的 sql,同时可以加一层 redis 缓存等

2周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!