当建立索引时,建议考虑以下几个方面:
索引的列数:在创建组合索引时,应当选择最左前缀列。例如,如果要在列A和列B上创建组合索引,则只能使用列A作为查询条件。 索引类型:如果选择B-tree索引,那么每个表至少一个索引,如果选择Hash索引,那么表最多只能有一个Hash索引。如果选择Full-Text Index全文索引,那么只能用于MyISAM和InnoDB引擎。 索引长度:在B-tree索引中,MySQL使用B树来存储数据,因此索引的长度会影响B树的高度和磁盘I/O操作的次数。因此,建议在创建B-tree索引时,尽量选择较短的列。 唯一性:如果希望某个列中的值是唯一的,可以使用唯一性索引。这样可以确保每个唯一值都有一个唯一的索引条目。 区分度:如果某个列中的值分布非常不均匀,可以使用区分度较高的索引。例如,可以使用区分度较高的列作为查询条件。 存储引擎:不同的存储引擎支持不同的索引类型和特性。例如,InnoDB支持全文索引(MyISAM不支持),而Memory存储引擎则不支持。 更新频率:如果某个列需要频繁更新,则建议不要在该列上创建索引,因为更新索引会带来额外的开销。 查询优化器:在创建索引时,应当考虑查询优化器的影响。如果某个查询使用某个索引,但优化器没有使用该索引,则可能会导致查询性能下降。 内存限制:创建大量索引会占用大量的内存资源。因此,在内存限制较大的情况下,应当限制创建的索引数量。 成本与收益:创建索引需要付出一定的成本,包括维护索引所需的CPU和磁盘I/O资源。因此,在创建索引时,应当权衡收益和成本之间的关系。只有在查询性能得到显著提升的情况下,才能认为创建索引是值得的。(来源sparkdesk)
自从接手公司dba,一直在用的MYSQL建表规范 1.id要bigint(21)自增主键,就算每秒1w次insert操作,100年也用不完;而且数据是连续的,不像uuid插入的时候要找位置。 2.所有varchar和char等字符串类型的列默认为空字符串 '',有些建表软件上是Empty String,如果业务不允许为null,还要加上not null。 3.每个表都要有create_time(datatime类型,默认值:CURRENT_TIMESTAMP)和update_time(datatime类型,默认值:CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP)而且要加上索引。普通索引格式为idx_columnname1_columnname2(column_name1,column_name2),唯一索引格式为idx_columnname1_columnname2(column_name1,column_name2)。 4.布尔类型的字段要以is_开头 unsigned无符号修饰,注意实体类不需要is_前缀。 5.表和列加上COMMENT备注,时间长了就不知道是做啥的了。 6.备用字段一般从reserve1到reserve8,字段类型为varchar(255)。 7.不要使用mysql保留字做表、列、索引名,尽量用英文单词不要用拼音。 8.表和列的字符集要统一,关联查询的列要加上索引,并且字段类型和编码方式要一致,否则会导致索引失效。 9.联合索引建立:关联查询的列作为第一级索引,查询条件作为二级索引,查询时候使用联合索引效率更高。 10.自增属性AUTO_INCREMENT设置为1。 11.表上面设置完字符集和排序规则之后,列就不用单独设置了。 12.字段需要关联其它表查询的,要加上单索引 idx_columnname;业务上需要唯一的,加上唯一索引 udx_columnname。 13.表字符集默认设置为utf8mb4,支持特殊字符和表情符号。 14.建表语句的默认选项 ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci,如果是主键自增的表 AUTO_INCREMENT = 1 行格式默认:ROW_FORMAT,不要单独设置。 15.字符类型列的长度除了备用字段,不要默认255,比如 company_id(36),如果使用UUID生成,32或36位就够了。
当创建索引时,以下几点是需要考虑的:
区分度:索引的区分度越高,查询效率就越高。一般来说,唯一的索引区分度最高,主键索引次之,非唯一索引的区分度相对较低。在建立非唯一索引时,最好在较短的字段上,尽量避免过长的字段作为索引,因为索引字段越长,则占用的磁盘空间和索引深度都会增加,从而降低查询效率。
数据类型:索引字段的数据类型和长度应当和实际数据的使用频率相符。例如,当数字类型索引字段的数据值范围较小时,使用小整数类型比大整数类型等会更加高效。
索引种类:对于不同的数据类型和查询条件,可能需要使用不同类型的索引。例如:对于模糊查询可以使用全文本索引或者通配符索引。
记录占用空间:对于包含大型字段的表,应该考虑将它们从索引中剔除,从而减少索引的存储空间。
适当的索引数量:如果索引太多会导致查询性能下降,因为每个索引都需要添加额外的开销;如果索引太少可能会导致性能下降,因为数据库需要扫描更多的数据来确定结果。
总之,索引的建立不仅仅是对于一个表,还涉及到查询和数据更新的需要考虑多方面的因素。
索引建立的建议包括: 1.根据实际查询需求建立索引,避免无用的索引占用空间; 2.对于经常查询的字段建立索引,提高查询效率; 3.对于数据量大的表,可以考虑分区索引,提高查询速度; 4.定期维护索引,删除无用的索引,优化索引结构,提高查询性能。
1、在用于where判断order排序和join的(on)、group by的字段上创建索引。 2、索引的个数不要过多,因为会浪费空间,更新变慢。 3、过长的字段,建立前缀索引。 4、宽度小的列优先建立索引。 5、区分度低的字段,例如性别,不要建索引,因为离散度太低,导致扫描行数过多。 6、频繁更新的值,不要作为主键或者索引,因为B+树的平衡会导致页分裂 ,影响效率。 7、随机无序的值,不建议作为索引,例如身份证、UUID,因为无序会到页分裂。 8、组合索引把散列性高(区分度高)的值放在前面。 9、创建复合索引,而不是修改单列索引。
云数据库Mysql版使用习惯同过去你使用开源Mysql习惯保持一致,比如过去单表索引不建议超过5个,重复性字段不建议建索引,联合索引字段不能太多等都是适用的,保持以往建索引习惯即可。
您好,索引不冗余不要建立过多索引,索引越多,插入性能越低,磁盘占用空间越多。我们推荐索引个数不要超过7个,并且不建议索引个数超过字段个数,特别是各种随机组合检索。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云关系型数据库主要有以下几种:RDS MySQL版、RDS PostgreSQL 版、RDS SQL Server 版、PolarDB MySQL版、PolarDB PostgreSQL 版、PolarDB分布式版 。