Java 写的一个接口， CPU 满载下只有 12 并发量......，如何改善

[337136897]

同事写的一个接口。就是查询评论这一块的，同时查询 6 张表吧。用阿里云服务器 4 核 8G 的，CPU 满载，并发只有 12。对，没错只有 12.然后我发现 mysqld 这个进程使用 cpu85%, 剩下的 15%才给了 JVM。 应该怎么去优化这个接口，12 并发是不给活啊

[neoblackcap]

@337136897 你的表都是没有索引的吗？你都贴了这么多了，何不将慢查询日志跟 explain 语句得到的查询计划一起发上来

[337136897]

@neoblackcap 数据量不多吧。所以没建索引。慢查询没开，晚点儿我去开一下。explain 语句是在哪里看？ - -

[jjwjiang]

这么多回复就 @neoblackcap 一条靠谱的
你倒是先确定是不是查询的问题呀……执行计划……查询日志
再不济你把语句一个 block 一个 block 慢慢删减，看看哪部分有最大的改善，别一上来就猜原因呀

[realpg]

一点数据库基础没有的还不会准备资料的从 0 开始提问学习 DB 优化

[weizhen199]

sql 优化，从 xjb 加索引开始

[neoblackcap]

@337136897 数据量不多是多少啊，你前面说同事建了索引，这里又全部隐藏了。你们性能调优都是靠散弹枪编程啊？还是撞大运编程？
explain 是 sql 语句啊，你 explain 一下你的 sql 语句就知道了，上面有人说了。再不行你先读 mysql 文档。
软件工程软件工程，不要都是靠猜啊。大胆猜想，实证分析，小心验证！

[micean]

粗看了下 sql
很多的 in 都可以优化成关联查询
group by 算数量的可以优化成缓存流程
DISTINCT 这个看你的数据量了

评论表为什么要拆成 2 张表

[akira]

表结构的索引 补一下，然后每个语句的 explain 补一下

[akira]

SELECT A.*,B.headIcon from `comt_like`AS A
left join (select userCode,headIcon FROM user_info) as B // 这个优化反效果了，每次都会对 user_info 表取一次全表，放外层会更好
on A.userCode = B.userCode
where commentCode in (
select commentCode FROM `comt_parent` where disType = #{disType}
)
ORDER BY commentCode,operationTime

[littlewing]

1. mysql 的 join 就是残废的，性能特别差，不要用
2. 不要用子查询

[veightz]

Java 一般都会 DAO 上再套 Manager 做缓存，不直接关联
评论这种走量的数据后续肯定会做分表，不用 join 趁早出坑

[kios]

数据库这块需要优化

[v2orz]

@sun1991 #11

现在普遍的说法是，DBMS 重点在存储，计算的工作尽量由应用做，尽管可能绝对效率不如 SQL 计算
因为应用扩展、拆分、后续维护都更容易

[xhinliang]

其实大型 Web 后端应用里，很少有连表查询的需求了。
甚至，索引都很少用，一般主键就够了。