知识大全 MySQL schema设计中的陷阱

Posted 2022-07-15 结构

篇首语：夫学须志也，才须学也。非学无以广才，非志无以成学。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 MySQL schema设计中的陷阱相关的知识，希望对你有一定的参考价值。

高性能MySQL：MySQL schema设计中的陷阱 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　 MySQL schema 设计中的陷阱

　　虽然有一些普遍的好或坏的设计原则但也有一些问题是由MySQL 的实现机制导致的这意味着有可能犯一些只在MySQL 下发生的特定错误本节我们讨论设计MySQL 的schema 的问题这也许会帮助你避免这些错误并且选择在MySQL 特定实现下工作得更好的替代方案

　　太多的列

　　MySQL 的存储引擎API 工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据然后在服务器层将缓冲内容解码成各个列从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的 MyISAM 的定长行结构实际上与服务器层的行结构正好匹配所以不需要转换然而 MyISAM 的变长行结构和InnoDB 的行结构则总是需要转换转换的代价依赖于列的数量当我们研究一个CPU 占用非常高的案例时发现客户使用了非常宽的表（数千个字段）然而只有一小部分列会实际用到这时转换的代价就非常高如果计划使用数千个字段必须意识到服务器的性能运行特征会有一些不同

　　太多的关联

　　所谓的实体属性值（EAV）设计模式是一个常见的糟糕设计模式尤其是在MySQL 下不能靠谱地工作 MySQL 限制了每个关联操作最多只能有张表但是EAV 数据库需要许多自关联我们见过不少EAV 数据库最后超过了这个限制事实上在许多关联少于张表的情况下解析和优化查询的代价也会成为MySQL的问题一个粗略的经验法则如果希望查询执行得快速且并发性好单个查询最好在个表以内做关联

　　全能的枚举

　　注意防止过度使用枚举（ENUM）下面是我们见过的一个例子

　　如果这里真和假两种情况不会同时出现那么毫无疑问应该使用枚举列代替集合列

　　非此发明（Not Invent Here）的NULL

　　我们之前写了避免使用NULL 的好处并且建议尽可能地考虑替代方案即使需要存储一个事实上的空值到表中时也不一定非得使用NULL 也许可以使用某个特殊值或者空字符串作为代替

　　但是遵循这个原则也不要走极端当确实需要表示未知值时也不要害怕使用NULL 在一些场景中使用NULL 可能会比某个神奇常数更好从特定类型的值域中选择一个不可能的值例如用代表一个未知的整数可能导致代码复杂很多并容易引入bug 还可能会让事情变得一团糟处理NULL 确实不容易但有时候会比它的替代方案更好

返回目录 高性能MySQL

编辑推荐

ASP NET MVC 框架揭秘

Oracle索引技术

ASP NET开发培训视频教程

cha138/Article/program/MySQL/201311/29680