标签：clustered-index performance mysql postgresql primary-key
在MySQL / InnoDB中,聚簇索引与主键同义,因此拾取较差的主键会影响数据库性能,即使用UUID作为PK是数据库写入的性能杀手.
现在,在PostgreSQL中,没有像MySQL这样的集群限制.如果我选择UUID作为PK有什么影响？数据库写性能杀手是否也像MySQL一样存在于PostgreSQL中？
解决方法:
MySQL的
虽然MySQL Documentation字面上说通常,聚集索引与主键同义,但它们不是同一个.请记住,the clustered index (called gen_clust_index)的创建方式使得PRIMARY KEY的索引页和表的行数据共存于同一页面中.拥有宽PRIMARY KEY值(例如UUID)会使BTREE页面更宽.它甚至可能导致数据页面分裂.由于MySQL中默认的innodb_page_size是16KB(这是一个fixed compiled-in value in MySQL 5.5 and back),因此您必须期望数据页面的行数更少,每个16KB页面的PRIMARY KEY导航空间更少.
我之前讨论了PRIMARY KEY的含义：见我的帖子InnoDB primary key efficiency
PostgreSQL的
A StackOverflow post from Peter Eisentraut表示B树索引中包含主键的值的最大长度是缓冲页大小的三分之一,默认为floor(8192/3)= 2730字节.
The maximum table size, row size, and maximum number of columns can be quadrupled by increasing the default block size to 32k. The maximum table size can also be increased using table partitioning.
从这里,假设您使用32K块而不是默认的8K块.你可以提供4倍以上的信息,但仍有某种限制.
幸运的是,UUID只有16个字节.我不希望它有惊天动地的弊端.
分析
InnoDB使用Clustered Index,命令不灵活,可以从较小的密钥中受益,并且由于不必管理在Clustered Index中分配密钥的空间,因此可以快速写入.
虽然PostgreSQL的存储引擎不像MySQL的InnoDB那样受限制或束缚,但较小的键肯定需要更快地处理并消耗更少的空间.这将增加PostgreSQL,MySQL或任何其他RDBMS的读写性能.
为了演示结构变化如何产生影响,让我们使用MySQL其他存储引擎MyISAM(非事务性且没有Clustered Index).我曾经使用MyISAM表并将其行格式从Dynamic更改为Fixed-Length,并且在不触及其他任何内容的情况下将性能提高了20％.我使数据更大,以获得更好的读取性能.写入性能也有所提高,因为触发任何空间管理的机制较少(参见我的文章What is the performance impact of using CHAR vs VARCHAR on a fixed-size field?).
只需阅读MySQL Documentation on Optimizing Data Size即可获得类似的短语
Smaller tables normally require less main memory while their contents are being actively processed during query execution.
Any space reduction for table data also results in smaller indexes that can be processed faster.
Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables. MEDIUMINT is often a better choice than INT because a MEDIUMINT column uses 25% less space.
为了进一步说明较小的数据类型,我提到MySQL的SELECT … PROCEDURE ANALYSE();.当您运行SELECT * FROM tablename PROCEDURE ANALYZE();时,输出是对数据,最小值,最大值,平均值,值的STD和(这是主要的一点)每列的推荐数据类型.
如果应用ALTER TABLE命令来应用推荐的数据类型,则表必须缩小.
甚至PostgreSQL也必须从较小的数据类型中受益.怎么样 ？
请回想一下PostgreSQL之前我已经讨论过这个叫做TOAST (The Outside Attribute Storage Technique)的机制(如果有大型列,请参阅我的帖子Proposal: MySQL blob handling revision必须处理行数据.显然,这个机制永远不会被触发,因为所有行都很小,很多行都适合PostgreSQL有8K块.
结论
既然你的问题似乎更集中在PostgreSQL上,那么让我回答你的问题：
What is the impact if I pick UUID as the PK? Does the database write performance killer also exists in PostgreSQL like in MySQL?
使用较小的列值,PostgreSQL可以更快地处理写入. UUID是16个字节.使用8字节整数作为PRIMARY KEY比UUID更快地编写和处理.一个4字节的整数甚至比这快.这一切的教训？如果您不需要,请不要使用更宽的PRIMARY KEY值减慢速度.
标签：clustered-index,performance,mysql,postgresql,primary-key 来源： https://codeday.me/bug/20190806/1597894.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。