MySQL表设计优化与索引

   设计好MySql的索引可以让你的数据库飞起来,大大的提高数据库效率。设计MySql索引的时候有一下几点注意:

  1.创建索引

  对于查询占主要的应用来说,索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的,或者说没有添加更为有效的索引导致。如果不加

  索引的话,那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描,如果一张表的数据量很大而符合条件的结果又很少,那么不加索引会引起致命的性能下

  降。但是也不是什么情况都非得建索引不可,比如性别可能就只有两个值,建索引不仅没什么优势,还会影响到更新速度,这被称为过度索引。

  2.复合索引

  比如有一条语句是这样的:select * from users where area=’beijing’ and age=22;

  如果我们是在area和age上分别创建单个索引的话,由于mysql查询每次只能使用一个索引,所以虽然这样已经相对不做索引时全表扫描提高了很多效

  率,但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age,

  salary)的复合索引,那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引,这被称为最佳左前缀

  特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减。

  3.索引不会包含有NULL值的列

  只要列中包含有NULL值都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

  4.使用短索引

  对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的 列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

  5.排序的索引问题

  mysql查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引。

  6.like语句操作

  一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

  7.不要在列上进行运算

  select * from users where

  YEAR(adddate)

  8.不使用NOT IN和操作

  NOT IN和操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替,id3则可使用id>3 or id

时间: 2024-08-03 20:07:57

MySQL表设计优化与索引的相关文章

MSSQL · 应用案例 · 日志表设计优化与实现

摘要 这篇文章从日志表问题引入.日志表的共有特性.日志表的设计需求.设计思路以及设计详细实现的角度,阐述了在SQL Server数据库中如何最优化设计日志表来降低系统资源的占用和提高系统吞吐量. 问题引入 在平时与客户服务与交流过程中,我们不止一次的被客人问及这样的场景:我们现在面临如何设计SQL Server日志表方案,如何最优化设计数据库日志记录表.因为,日志表设计会面对如下问题: 表记录数大:日志表由于记录了应用程序的很多操作日志,有的业务有很多步骤,甚至每个步骤操作都会被记录到日志表中

MSSQL-应用案例-日志表设计优化与实现

title: MSSQL-应用案例-日志表设计优化与实现 author: 风移 摘要 这篇文章从日志表问题引入.日志表的共有特性.日志表的设计需求.设计思路以及设计详细实现的角度,阐述了在SQL Server数据库中如何最优化设计日志表来降低系统资源的占用和提高系统吞吐量. 问题引入 在平时与客户服务与交流过程中,我们不止一次的被客人问及这样的场景:我们现在面临如何设计SQL Server日志表方案,如何最优化设计数据库日志记录表.因为,日志表设计会面对如下问题: 表记录数大:日志表由于记录了

基于Solr DIH实现MySQL表数据全量索引和增量索引

实现MySQL表数据全量索引和增量索引,基于Solr DIH组件实现起来比较简单,只需要重复使用Solr的DIH(Data Import Handler)组件,对data-config.xml进行简单的修改即可.Solr DIH组件的实现类为org.apache.solr.handler.dataimport.DataImportHandler,在Solr的solrconfig.xml中配置两个handler,配置分别说明如下. 全量索引 solrconfig.xml配置如下: 1 <reque

mysql表优化、分析、检查和修复的方法详解_Mysql

本文实例讲述了mysql表优化.分析.检查和修复的方法.分享给大家供大家参考,具体如下: 这里介绍对数据库的管理常规就是进行预防性的维护,以及修复那些出现问题的内容. 进行检查和修复通常具有四个主要的任务: 1. 对表进行优化 2. 对表进行分析(分析并存储MyISAM和BDB表中键的分布) 3. 对表进行检查(检查表的错误,并且为MyISAM更新键的统计内容) 4. 对表进行修复(修复被破坏的MyISAM表) 一.对表进行优化 优化表有很多方式实现: OPTIMIZE TABLE语句.mysq

数据库系统优化:业务逻辑设计优化

当我们优化一个系统时,有时发现一种情况就是自己修改SQL,索引以及分区是不能解决性能问题的.这时你要考虑业务逻辑优化和表设计的重构.这两点的确和设计结合的很紧密. 业务逻辑优化 结合实际,我们先谈谈业务逻辑优化. 案例一: 我们的系统一个文档模块,客户点击时很慢,通过性能分析,是点击是去查询数据库,这时系统是通过Hibernate来两步处理: 1,计算该类型的文档数量总数. 2,显示最新文档的前20篇文档. 这时显示第二步的时间是很快的,只取20条记录,但是计算该类型的所有总数很慢.系统的这时的

Mysql数据表的优化方法总结

优化表的数据类型 表需要使用何种数据类型,是需要根据应用来判断的.虽然应用设计的时候需要考虑字段的长度留有一定的冗余,但是不推荐让很多字段都留有大量的冗余,这样即浪费存储也浪费内存. 我们可以使用PROCEDURE ANALYSE()对当前已有应用的表类型的判断,该函数可以对数据表中的列的数据类型提出优化建议,可以根据应用的实际情况酌情考虑是否实施优化.语法:  代码如下 复制代码    SELECT * FROM tbl_name PROCEDURE ANALYSE();    SELECT

MySQL数据库性能优化之表结构优化

很多人都将<数据库设计范式>作为数据库表结构设计"圣经",认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求.殊不知,在N年前被奉为"圣经"的数据库设计3范式早就已经不完全适用了.这里我整理了一些比较常见的数据库表结构设计方面的优化技巧,希望对大家有用. 这是 MySQL数据库性能优化专题 系列的第二篇文章:MySQL 数据库性能优化之表结构优化 系列的第一篇文章:MySQL 数据库性能优化之缓存参数优化

【沉淀】一张表的设计优化节省了两百万,客户不断盛誉……,这背后他究竟做对了什么?——记访谈阿里云汪建明

<沉淀>是展示专家风采的人物栏目.它呈现每个专家独一无二的人生经历.认识和感悟的同时,也能帮助你沉淀技术,收获对技术和人生的判断.我们的想法是:"若你想精进为一个很厉害的人,不妨细细品味这些技术牛人背后的沉淀."如果你想了解这些云栖专家更多分享时,请点击云栖专家频道,当然我们也欢迎你往前走一步,成为我们的云栖专家(https://yq.aliyun.com/expert),与技术大牛一起"煮酒论英雄". "客户第一"是阿里巴巴&quo

Mysql数据库性能优化三(分表、增量备份、还原)_MsSql

接上篇Mysql数据库性能优化二 对表进行水平划分           如果一个表的记录数太多了,比如上千万条,而且需要经常检索,那么我们就有必要化整为零了.如果我拆成100个表,那么每个表只有10万条记录.当然这需要数据在逻辑上可以划分.一个好的划分依据,有利于程序的简单实现,也可以充分利用水平分表的优势.比如系统界面上只提供按月查询的功能,那么把表按月拆分成12个,每个查询只查询一个表就够了.如果非要按照地域来分,即使把表拆的再小,查询还是要联合所有表来查,还不如不拆了.所以一个好的拆分依据