- 主题:mysql性能比pg差大节啊
问题是如果是中间机构,没法应用前缀匹配
【 在 fanci 的大作中提到: 】
: 抛开数据库不谈,窃以为这个查询里的 concat改成前缀匹配,可以提升速度10倍
--
FROM 119.139.198.*
chatgpt 推荐用 select find_in_set('path2', replace('/path1/path2/path3/','/','
,'));
不知道这个性能如何
【 在 fanci 的大作中提到: 】
: 抛开数据库不谈,窃以为这个查询里的 concat改成前缀匹配,可以提升速度10倍
--
FROM 119.139.198.*
因为简单好配,能快速搭网站,所以php才标配mysql
pg安装完后,几个conf的配置都要难倒一批新手。
【 在 roy 的大作中提到: 】
: 当年mysql火是因为php标配吧
--
FROM 58.42.245.*
应该看看执行计划,至要少知道优化器是怎么想的
【 在 iwannabe 的大作中提到: 】
: 有一个表dept_index,是这样的
: dept_id
: dept_path
: ...................
--
FROM 1.119.194.*
你这是结果了
【 在 roy 的大作中提到: 】
: 当年mysql火是因为php标配吧
--
FROM 116.233.79.*
t2.dept_path like concat('%/',t1.dept_id,'/%')
要是改成
t2.dept_path like concat(t1.dept_path, t1.dept_id, '/%')
语义还对不,能有改进不?
【 在 iwannabe 的大作中提到: 】
: 问题是如果是中间机构,没法应用前缀匹配
:
--
FROM 115.171.20.*
pg对join优化比mysql多吧
--
FROM 36.110.223.*
这个编程规范哪里有?
【 在 adoal 的大作中提到: 】
: 所以为啥四十大盗厂的Java编程规范里对MySQL各种限制,
: 连表查询不超过多少个之类的……稍微复杂一点就跪了。
:
--
FROM 180.104.104.*
性能差是dba的事情,
写代码的操什么闲心?
把dba的活全都干了,
回头又抱怨卷得厉害。
【 在 iwannabe 的大作中提到: 】
: 有一个表dept_index,是这样的
: dept_id
: dept_path
: ...................
--
FROM 49.5.197.*