MySQL和PostgreSQL中的聚簇索引性能考虑因素
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySQL和PostgreSQL中的聚簇索引性能考虑因素，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3460字，纯文字阅读大概需要5分钟。
内容图文
在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值减慢速度.
内容总结
以上是互联网集市为您收集整理的MySQL和PostgreSQL中的聚簇索引性能考虑因素全部内容，希望文章能够帮你解决MySQL和PostgreSQL中的聚簇索引性能考虑因素所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。