mysql数据库sql语句调优 、

mysql数据库sql语句调优 、

索引设计原则:

索引列一般为where子句中的列或连接字句中的列

尽量不对基数小的列做索引,如性别列

尽可能使用短索引:如果对字符列索引尽量指定最小长度。

(short Keys are better,Integer best)

create index cityname on city(city(10));

复合索引前缀特性,索引的顺序很重要。

key(a,b,c)联合索引:

可以走索引的组合:key(a),key(a,b ),key(a,b,c)

下列索引无法走索引key(b),key(b,c),key(a,c)

key(a,b)...where b=5 will not use index

创建复合索引时应将最常用作限制条件列放在最左边,依次递减

避免出现无用的索引。(很少使用或从未别调用)

INNODB:尽量指定主键,最常用较短数据类型,唯一列做主键。

尽量使用定长字符类型char,而不用varchar

对于索引的优化,当使用联合索引时,将常用的列在索引的左边,不常用的列,取其前部分字符,只要能精确查到它即可

例如:

create index d_a_p on ad_oldboy_detal(dateline,),ader(ader(20),pos(20));

避免过度使用索引

1.索引的建立对提高检索能力很有用,但是数据库维护它也很费资源。

2.对性别列索引,被称为过度索引。

只有两个值,建索引不仅没优势,还会影响到插入,更新速度,

3,索引会占用磁盘空间,降低更新操作性能,且执行计划要考虑各个索引

4.索引不是越多越好。

5行数比较少的表可以不建索引(100行以内)

创建索引的语法

help create index

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type]

index_col_name:Col_name:[(length)] [ASC|DESC]

Phpadmin:

ALTER TABLE `pw4_group_art` ADD INDEX(`tid`)

create index pw4_group_art_tid on pw4_group_art(tid);

删除索引语法

drop INDEX ind_sage on student;

复合索引及前N个字符索引例子集合;

create index Sage_Sdet on student(sname,sage(100)

查询一个语句,看他有没有走索引;

explain  select * from student where Sno=6

只要key不为空,

如果数据库有缓存,想测试速度,应该

explain SQL_NO_CACHE* from uc_members where email="1234";

查看表的唯一值多少,用distinct;

select count(distinct Sage) from student;

使用索引的条件

1:索引列不能包含空值

2:复合索引中只要有一列含有null值,那么这一列将不会使用索引

3:列类型是字符串,要在where条件中吧字符值用引号括起来。

4:用or分割开的条件,or前条件有索引,而后面列无索引,那么设计的索引都不会被用到

5:条件不是索引列的第一部分

5:like语句操作

一般情况下尽量不使用like操作。like "%aaa%" 不会使用索引,而like,"aaa%"可以使用索引。可以建立fulltext或者sphinx(斯芬克司)

6:不要在列上进行运算

select  * from users where YEAR(adddate)<2007;将在每个行上进行运算,这将导致索引失效而进行全表扫描,因此我们可以改成select* from users where addate<‘2007-07-01‘;

7:不使用NOT IN  和<>操作

NOT IN 和<>操作多不会使用索引将进行全表扫描,NOT IN 可以 NOT EXISTS代替,id<>3 则则可使用id>3orid<3来代替

其他;

尽量用连接查询代替子查询(嵌套查询)

order by 的索引问题

show processlist 查看线程

show full processlist

uptime

在生产环境中如果是大表,创建索引会很耗费时间,也许需要几分钟,要把索引放在业务的低谷

explian看看有没有走索引

show processlist;

在看看优化之后负载的变化

优化的起因:

1 网站出问题,很慢show full processlist--->

2:慢查询语句(日志文件)

grep slow my.cnf

只要是

long_query_time=1

log-slow-queries=/data/3306/slow.log

不要强求所有的列进行走索引

让大表常用的列走索引,一般来说就可以了

时间: 2024-08-04 03:37:10

mysql数据库sql语句调优 、的相关文章

使用MySQL数据库 SQL语句

1.查看当前服务器数据库中有哪些库? SHOW   DATABASES;   ###查看有哪些库 2.查看当前使用的库有哪些表? USE +要查询的库名 SHOW   TABLES; ###查询库中有哪些表 3.查看标的结构? USE  +要使用的库名 DESCRIBE  +表名 ###查看表结构 4.创建新的库? CREATE   DATABASE +表名  ###创建库 5.创建新的表 CREATE   TABLE +表名 (字段1名称   类型 ,字段2名称   类型,...)  ###创

MySQL数据库sql语句的一些简单优化

1.查询条件的先后顺序 有多个查询条件时,要把效率高能更精确筛选记录的条件放在后边.因为MySQL解析sql语句是从后往前的(不知是否准确). 例: select a.*,b.* from UsrInf a,OrgInf b where LogNam='njnydx9' and b.OrgId=a.blnorg SQL语句从后往前解析,把LogNam='njnydx9'换到后边,避免了更多结果集的连接,提高了执行效率 2.in的效率问题 看网上都说in相当于多个条件的or.实际测试后发现in的执

MySQL千万级多表关联SQL语句调优

本文不涉及复杂的底层数据结构,通过explain解释SQL,并根据可能出现的情况,来做具体的优化,使千万级表关联查询第一页结果能在2秒内完成(真实业务告警系统优化结果). 需要优化的查询:使用explain 出现了Using temporary: 有分页时出现了Using filesort则表示使用不了索引,需要根据下面的技巧来调整语句 rows过多,或者几乎是全表的记录数: key 是 (NULL): possible_keys 出现过多(待选)索引. 1.使用explain语法,对SQL进行

SQL语句调优三板斧

改装有顺序------常开的爱车下手 你的系统中有成千上万的语句,那么优化语句从何入手呢 ? 当然是系统中运行最频繁,最核心的语句了.废话不多说,上例子: 这是一天的语句执行情况,里面柱状图表示的是对应执行时间段内语句的次数,总体看起来长时间语句非常多. 下面看一下具体的语句执行情况: 排位第一的语句执行次数38508次,是一个存储过程(RPC:Completed 表示存储过程结束,不知道这个的请看profiler的使用说明).其中的一条语句(SP:StmtCompleted)也就是排在第二位的

SQL语句调优

sql语句优化原则 性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几

mysql数据库sql语句

数据库(mysql) sql是一种编程语言,用于存储,查询,更新,管理关系型数据库 分为四类: DDL:数据定义语言 //针对于数据库和表,creat drop alter select DCL:数据控制语言 //grant...if DML:数据操纵语言 //操作表中数据,insert delete update DQL:数据查询语言 //查询:select 1.数据库的创建/删除/查/切换 a)Create database 数据库名称 //创建数据库 b)Drop database 数据库

千万级大数据的Mysql数据库SQL语句优化

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:select id from t where num is null可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则引擎将放弃使用

SQL 语句调优 where 条件 数据类型 临时表 索引

基本原则 避免全表扫描 建立索引 尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理 尽量避免大事务操作,提高系统并发能力 使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效.尽量避免使用游标,因为游标的效率较差. where 后的条件 应尽量避免在 where 子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描. 应尽量避免在 where 子句中使用 or 来连接条件,可以考虑使用union 代替 in 和

SQL Server调优系列玩转篇三(利用索引提示(Hint)引导语句最大优化运行)

前言 本篇继续玩转模块的内容,关于索引在SQL Server的位置无须多言,本篇将分析如何利用Hint引导语句充分利用索引进行运行,同样,还是希望扎实掌握前面一系列的内容,才进入本模块的内容分析. 闲言少叙,进入本篇的内容. 技术准备 数据库版本为SQL Server2012,利用微软的以前的案例库(Northwind)进行分析,部分内容也会应用微软的另一个案例库AdventureWorks. 相信了解SQL Server的朋友,对这两个库都不会太陌生. 一.并行Hint提示 (MAXDOP N