我技术很烂，请尽量提供一些可能被笨蛋忽略的内容。比如不能只测查询，还要测相应的增删改。网上能搜到一点东西，但总感觉不放心。
之前我问了个问题： https://www.v2ex.com/t/1173631 。就一个回复，而且还那么多点击，感觉应该是不太行了。所以打算自己测试了。
 |
1
michael2016 21 小时 0 分钟前  1
做数据库性能测试时，建议遵循 “基准 -> 负载 -> 极限 -> 稳定性” 的顺序。不要一上来就压垮数据库，而是要先建立基准，然后逐步加压，观察瓶颈是先出现在 CPU 、I/O 还是锁冲突上。
测试不仅仅是“跑分”，更重要的是“调优”。当性能不达标时，检查以下层面： SQL 语句优化: 这是最常见的原因,检查是否存在全表扫描、慢查询（ Slow Query ）、复杂的关联查询（ Join ）。 索引 (Indexing): 索引是否缺失？或者索引失效？过多的索引也会影响写入性能。 锁机制 (Locking): 是否存在大量的行锁竞争、死锁（ Deadlock ）？高并发下，锁等待时间过长会由数据库层面拖垮应用。 配置参数 (Configuration): MySQL: innodb_buffer_pool_size, max_connections, innodb_flush_log_at_trx_commit 等。 PostgreSQL: shared_buffers, work_mem, max_connections 等。 硬件瓶颈: 磁盘是 HDD 还是 SSD ？ RAID 级别是什么？ CPU 核数是否足够？内存是否够用？网络或磁盘 IO |
 |
2
CEBBCAT 20 小时 40 分钟前 1
|
 |
5
yjhatfdu2 20 小时 26 分钟前
主要还是看你的业务需求，按照实际使用情况，设计测试用例，然后使用测试工具测试。比如你的场景可以按照预期的标签数量、写入查询的比例，并且适当放大，然后用 pgbench 等来压测，观察 cpu 、内存、IO 、连接数之类的压力。另外，还可以用 explain analyse 来详细分析单个查询是不是比较科学，有没有优化空间。顺便，#2 这样分段这么清楚，说的这么清楚但是不贴合问题的，一眼 AI
|
|
6
CEBBCAT 20 小时 25 分钟前
|
|
7
yjhatfdu2 20 小时 18 分钟前
@CEBBCAT 这个回答一看就没有看 OP 的原问题，原问题是描述了一个具体的场景的，而且明确是 postgresql ，而这个回复十分的通用甚至没有回答正文的内容，只能回复”数据库性能测试的要点有哪些？“，而且标点格式十分规范，英文标注，引号的使用，十分像不是很高级的 AI
|
 |
8
ntedshen 19 小时 56 分钟前
你业务都没铺开就不要去想 benchmark 。。。
我不是说这么干没意义。。。 但是第一个，别人看不懂你什么想法 第二个，业务你要跑不通，做什么都是白搭。。。 |
 |
9
deplives 19 小时 55 分钟前
|
 |
11
AutumnVerse 18 小时 48 分钟前 via iPhone
@shendaowu 别瞎想了，现代数据库已经非常强大了，强大的你啥都不要做，撑几万几十万 qps 轻轻松松，你业务要多久才能到这规模
当你真到这个瓶颈的时候，你也会发现扩容也很简单，几乎啥都不用干，加几台机器，性能又能翻几倍 |
 |
12
shendaowu OP @AutumnVerse #11 问题是我的花活是一般人强烈不建议的。他要是个点查我才不会管。我怕它出现类似组合爆炸的问题。我只是个野生程序员，我的直觉和经验都不够，不敢猜和想。
|
|
13
ntedshen 18 小时 9 分钟前 1
|
 |
14
songco 14 小时 5 分钟前 via Android 1
多年前搞过类似的测试
主要方式是模拟负载 有两种，一种是抓生产环境负载，一天或者一周的，然后按时间发起请求记录每个请求响应时间，有可能需要放大 还有就是算法模拟负载，比如 80%热点之类的 有条件第一种比较好 主要是身边环境数据比较真实（比如实现的比较烂），很多测试过于简单了 当然影响因素太多了，其实很难对比，当年我们的产品，各种优化，量上去了还是性能问题（比如银行客户，某些奇怪用法），后来 ssd 开始慢慢用于生产环境，我们自己测试，换 ssd 后数据库参数优化一下，性能 50 倍起步，之前各种折腾也就提升了大概 4-5 倍的样子，改动了好多设计，各种 migration ，之后就是建议客户上 ssd |
Select Language