阅读使人充实，讨论使人敏捷，写作使人精确。

>>> 压测业务场景文章属于互联网社区动态类场景核心功能压测案例。至于题目涉及的MySQL和PostgreSQL之间的关系，主要为业务选型积累基础参考，并非为了抬高谁、贬低谁，其实很多情况，两者皆可。期盼国内MySQL和PostgreSQL可以互相借鉴、吸收。本次压测的主要功能点为业务实时关注社区动态以下4点：1.最新发表动态；2.动态最新评论；3.社区话题精华；4.社区话题等动态列表置顶。

温馨提示：文章压测结果仅供参考，不代表官方性能测试结论。 

>>> 压测环境介绍

>>> 环境内部配置1.MySQL使用TDSQL(基于MySQL-5.7.17)，开启并行复制

1)基于LOGICAL_CLOCK，64个线程并行复制；2) group commit使用COMMIT_ORDER;3) master_info_repository=TABLE，relay_log_info_repository=TABLE。4) 设置不可退化强同步(至少一个同城slave同步，否则master挂起)。5) 主从刷盘双“1”配置。

2.PostgreSQL使用Tbase-v2(基于PostgreSQL-10.5)，采用PGXL1)cn节点pooler配置

postgres=# show pooler_scale_factor; pooler_scale_factor --------------------- 16(1 row)postgres=# show persistent_datanode_connections; persistent_datanode_connections --------------------------------- on(1 row)postgres=# 

2)dn节点

pooler_scale_factor = 16

3)主从同步同城any one强同步，主库配置

postgres=# show synchronous_commit; synchronous_commit -------------------- on(1 row)postgres=# show synchronous_standby_names; synchronous_standby_names  ---------------------------- ANY 1 (100.xx.xxx.52:5436)(1 row)postgres=#

>>> 表结构及压测SQL文本注：本文表结构及索引设计已经多次调优整改，剩余优化空间较小。1.MySQL表结构：shardkey=test_id

"tab_target | CREATE TABLE `tab_target` (  `test_id` bigint(20) NOT NULL,  `moment_id` bigint(20) NOT NULL,  `creator` bigint(20) NOT NULL,  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `comment_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `complex_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `status` smallint(5) unsigned NOT NULL DEFAULT '0',  `is_essence` smallint(5) unsigned NOT NULL DEFAULT '0',  `set_essence_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `is_top` smallint(5) unsigned NOT NULL DEFAULT '0',  `set_top_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `visible_range` smallint(5) unsigned NOT NULL DEFAULT '0',  `is_hide` smallint(5) unsigned NOT NULL DEFAULT '0',  `set_hide_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  PRIMARY KEY (`test_id`,`moment_id`),  KEY `idx_comp02` (`test_id`,`status`,`visible_range`,`is_hide`,`is_essence`),  KEY `idx_comp03` (`test_id`,`status`,`visible_range`,`is_hide`,`is_essence`,`moment_id`,`creator`,`create_time`,`comment_time`,`complex_time`),  KEY `idx_comp01` (`test_id`,`create_time`,`moment_id`),  KEY `idx_comp04` (`test_id`,`is_essence`,`status`,`is_hide`,`create_time`,`moment_id`),  KEY `idx_comp05` (`test_id`,`is_top`,`moment_id`),  KEY `idx_comp06` (`test_id`,`complex_time`,`moment_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 shardkey=test_id "

‍2.PG表结构：Distribute By: SHARD(test_id)

akendb=# \d+ tab_target                                                      Table ""public.tab_target""      Column      |           Type           | Collation | Nullable |               Default               | Storage | Stats target | Description ------------------+--------------------------+-----------+----------+-------------------------------------+---------+--------------+------------- test_id     | bigint                   |           | not null |                                     | plain   |              |  moment_id        | bigint                   |           | not null |                                     | plain   |              |  creator          | bigint                   |           | not null |                                     | plain   |              |  create_time      | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              |  comment_time     | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              |  complex_time     | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              |  status           | smallint                 |           |          | 0                                   | plain   |              |  is_essence       | smallint                 |           |          | 0                                   | plain   |              |  set_essence_time | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              |  is_top           | smallint                 |           |          | 0                                   | plain   |              |  set_top_time     | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              |  visible_range    | smallint                 |           |          | 0                                   | plain   |              |  is_hide          | smallint                 |           |          | 0                                   | plain   |              |  set_hide_time    | timestamp with time zone |           |          | to_timestamp((0)::double precision) | plain   |              | Indexes:    ""tab_target_unique_constraint"" UNIQUE CONSTRAINT, btree (test_id, moment_id)    ""tab_target_test_id_create_time_moment_id_idx"" btree (test_id, create_time, moment_id) WHERE status = 0 AND visible_range <> 200 AND is_hide = 0 AND is_essence = 1    ""tab_target_test_id_create_time_moment_id_idx1"" btree (test_id, create_time, moment_id) WHERE test_id = 239 AND status = 0 AND visible_range <> 200 AND is_hide = 0    ""tab_target_test_id_set_top_time_idx"" btree (test_id, set_top_time) WHERE status = 0 AND visible_range <> 200 AND is_hide = 0 AND is_top = 1    ""condit_complex_idx"" btree (test_id, complex_time, moment_id) WHERE status = 0 AND visible_range <> 200 AND is_hide = 0    ""idx_comp"" btree (test_id, status, visible_range, is_hide)Distribute By: SHARD(test_id)Location Nodes: dn001akendb=#

3.核心功能点SQL语句1)MySQL语句：

--置顶列表:SELECT moment_id FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_top = 1 AND is_hide = 0 order by set_top_time desc LIMIT 1000;--最新发布:SELECT moment_id,creator,UNIX_TIMESTAMP(create_time) as create_time_1,UNIX_TIMESTAMP(comment_time) as comment_time_1,UNIX_TIMESTAMP(complex_time) as complex_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 order by create_time desc, moment_id desc limit 1000;--最新评论:SELECT moment_id,creator,UNIX_TIMESTAMP(create_time) as create_time_1,UNIX_TIMESTAMP(comment_time) as comment_time_1,UNIX_TIMESTAMP(complex_time) as complex_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 order by complex_time desc, moment_id desc limit 1000;--只看精华:SELECT moment_id,creator,UNIX_TIMESTAMP(create_time) as create_time_1,UNIX_TIMESTAMP(comment_time) as comment_time_1,UNIX_TIMESTAMP(complex_time) as complex_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 AND is_essence = 1 order by create_time desc, moment_id desc limit 1000;

2)PostgreSQL语句：

--置顶列表:SELECT moment_id FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_top = 1 AND is_hide = 0 order by set_top_time desc LIMIT 1000;--最新发布:SELECT moment_id,creator,(date_part('epoch', create_time))::bigint as create_time_1,(date_part('epoch', comment_time))::bigint as create_time_1,(date_part('epoch', complex_time))::bigint as create_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 order by create_time desc, moment_id desc limit 1000;--最新评论:SELECT moment_id,creator,(date_part('epoch', create_time))::bigint as create_time_1,(date_part('epoch', comment_time))::bigint as create_time_1,(date_part('epoch', complex_time))::bigint as create_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 order by complex_time desc, moment_id desc limit 1000;  --只看精华:SELECT moment_id,creator,(date_part('epoch', create_time))::bigint as create_time_1,(date_part('epoch', comment_time))::bigint as create_time_1,(date_part('epoch', complex_time))::bigint as create_time_1 FROM tab_target WHERE test_id = 239 AND status = 0 AND visible_range != 200 AND is_hide = 0 AND is_essence = 1 order by create_time desc, moment_id desc limit 1000;

>>> 读请求压测结果

1.单次读性能对比

1)数据量85w

2)数据量：2.7亿(64分片)

2.并发读性能对比：1)数据量：85w

2)数据量：2.7亿(64分片)

注：单分片数据量达到4千万以上，理论上增加分片的情况下，MySQL的性能应该还会有所提升。>>> 写请求压测结果1.随机写配置：

--MySQL语句样例REPLACE INTO tab_target(test_id, moment_id, creator, create_time, complex_time, status, is_essence, set_essence_time, is_top, set_top_time, is_hide, set_hide_time, visible_range) VALUES(239, 652763263, 1286241, '2020-10-12 11:11:21', '2020-10-12 11:11:21', 1, 0, '2020-10-12 11:11:21', 1, '2020-10-12 11:11:21', 1, '2020-10-12 11:11:21', 0);--PostgreSQL语句样例INSERT INTO tab_target(test_id, moment_id, creator, create_time, complex_time, status, is_essence, set_essence_time, is_top, set_top_time, is_hide, set_hide_time, visible_range) VALUES(239, 861227078, 8223700, '2020-09-29 17:33:29', '2020-09-29 17:33:29', 1, 0, '2020-09-29 17:33:29', 0, '2020-09-29 17:33:29', 1, '2020-09-29 17:33:29', 0) ON CONFLICT ON CONSTRAINT tab_target_unique_constraint DO UPDATE SET status=1, is_essence=0, set_essence_time='2020-09-29 17:33:29', is_top=0, set_top_time='2020-09-29 17:33:29', is_hide=1, set_hide_time='2020-09-29 17:33:29', visible_range=0, create_time='2020-09-29 17:33:29', complex_time='2020-09-29 17:33:29'"

2.单次写性能对比：

3.并发写性能对比：

>>> 压测结论1.读请求总结1)上述语句单次读请求，部分语句在MySQL的表现稍微优于PostgreSQL，并发较低的简单查询业务场景，两者整体相差不大。2)上述语句并发读请求，MySQL接入机比pg分布式cn消耗更小的CPU资源，但整体的QPS能力及稳定性PostgreSQL较高。3)补充一下，MySQL在字段函数计算上内核态会消耗更多CPU，上述语句中UNIX_TIMESTAMP函数需剥离到客户端或业务逻辑实现，否则200并发可将整个服务器CPU耗完。2.写请求总结1)上述语句单次随机写，MySQL比PostgreSQL要好，主要原因在于两者之间的强同步方式有所区别，说明pg强同步对写入性能有较大影响。2)上述语句并发写，PostgreSQL同步保障在毫秒级，MySQL无论是同步方式还是异步方式，单节点TPS>8000时有明显同步延迟。

温馨提示：文章压测结果仅供参考，不代表官方性能测试结论。 

往期推荐

1.MySQL-用最简单实用的方法将SQL性能提升100倍

2.MySQL日常运营重要事项存在问题总结

3.PostgreSQL数据库TPCC测试-Banchmarksql 5.0部署详解

                                 ——让学习成为一种习惯-Aken

感谢阅读