标签:系统命令 操作系统 hash表 关系 导致 规则 主从 数据库索引 就是
MySQL是一个关系型数据库管理系统,属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一,在 WEB 应用方面,MySQL是最好的RDBMS (Relational Database Management System,关系数据库管理系统) 应用软件之一。在Java企业级开发中非常常用,因为MySQL 是开源免费的,并且方便扩展。
数据库索引可快速地寻找那些具有特定值的记录。索引的原理很简单,首先,数据库索引,是数据库管理系统中一个排序的数据结构,其次,在插入索引时会对创建了索引的列的内容自动排序,并将排序结果生成倒排表。最后,在查询时只需要先拿到倒排表内容,再根据索引取出数据地址链,就能轻松拿到具体数据。其中,索引的优缺点在于:
索引的数据结构和具体存储引擎的实现有关,我们经常使用的InnoDB存储引擎的索引包括B+树索引(默认方式)和HASH索引两种。
通常,通过索引查询数据比全表扫描要快,但我们也必须注意到它的代价:索引需要空间来存储,也需要定期维护, 每当有记录在表中增/删/改时,索引本身也会被修改,这意味着每条记录的增/删/改将为此多付出4、5 次的磁盘I/O操作,这些操作会降低增/删/改的执行效率。所以,在我们删除数据库百万级别数据的时候,查询MySQL官方手册得知删除数据的速度和创建的索引数量是成正比的。所以我们想要删除百万数据的时候可以先删除索引(此时大概耗时三分多钟),然后删除其中无用数据(此过程需要不到两分钟),删除完成后重新创建索引(此时数据较少了)创建索引也非常快,约十分钟左右。与之前的直接删除绝对是要快速很多,更别说万一删除中断,一切删除会回滚,那更是坑了。
主键是数据库确保数据行在整张表唯一性的保障,即使业务上本张表没有主键,也建议添加一个自增长的ID列作为主键。设定了主键之后,在后续的删改查的时候可能更加快速。
在主键设置上,推荐使用自增ID,不推荐使用UUID,原因在于:在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据,如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入、数据移动,导致产生很多内存碎片,造成插入性能的下降。
一个好的数据库设计方案对于数据库性能往往会起到事半功倍的效果。常见的数据库结构优化方案如下:
背景:对于字段较多的表,如果有些字段的使用频率较低,会导致当该表的数据量很大时,SQL操作会因使用频率低的字段的存在而变慢。
解决:对于字段较多的表,如果有些字段的使用频率很低,可以将这些字段分离出来形成新表。
对于需要经常联合查询的表,可以建立中间表以提高查询效率。通过建立中间表,将需要通过联合查询的数据插入到中间表中,然后将原来的联合查询改为对中间表的查询。
设计数据表时应尽量遵循范式理论的规约,尽可能的减少冗余字段(属性重复),让数据库设计看起来精致、优雅。但是完全去冗余也是有问题的,当表和表之间的关系越多,需要连接查询的情况也就越多,sql语句就会变得异常庞大与臃肿,并且逻辑非常的复杂,一般在这种情况下数据库要解析我们的sql运行,查询的速度会变得非常慢,对于用户的体验感也会受到影响,当再次需要修改功能时,可能也会对这个sql进行修改,对于我们之后维护与升级也会变得相当的麻烦。这时如果我们适当的把数据进行冗余,我们sql由臃肿给人一种便捷清晰的感觉,没有那么复杂的逻辑,对于之后的维护也会随之变得便利起来,运行速度也会随之提升增强,用户的体验感也会增强!
标签:系统命令 操作系统 hash表 关系 导致 规则 主从 数据库索引 就是
原文地址:https://www.cnblogs.com/huaiheng/p/13221779.html