锐客网

  1. 首页 > 生活百科 > it技术 > >

mysql查询怎么那么难 mysql 查询很慢原因

索引IT技术

mysql查询 很有难度CREATE FUNCTION dbo.f_str(@id int)
RETURNS varchar(8000)
AS
BEGIN
DECLARE @r varchar(8000)
SET @r = ''
SELECT @r = @r','value FROM tb WHERE class=@id
RETURN STUFF(@r, 1, 1, '')
END
GO
-- 调用函数
SELECt class, name = dbo.f_str(id) FROM tb GROUP BY id
在sqlserver2000环境下可以运行!
Mysql 查询速度慢怎么办问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表 ， 但是在 MySQL 5.7 上运行特别慢 ， 怎么办？
实验
我们搭建一个 MySQL 5.7 的环境 ， 此处省略搭建步骤 。
写个简单的脚本，制造一批带主键和不带主键的表：
执行一下脚本：
现在执行以下 SQL 看看效果：
...
执行了 16.80s ， 感觉是非常慢了 。
现在用一下 DBA 三板斧，看看执行计划：
感觉有点惨，由于 information_schema.columns 是元数据表，没有必要的统计信息 。
那我们来 show warnings 看看 MySQL 改写后的 SQL：
我们格式化一下 SQL：
可以看到 MySQL 将
select from A where A.x not in (select x from B) //非关联子查询
转换成了
select from A where not exists (select 1 from B where B.x = a.x) //关联子查询
如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：
select from A where A.x not in (select x from B where ...) //非关联子查询:1. 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2. 扫描 A 表中的记录 ， 与临时表 C 中的记录进行比对，直接在索引里比对，
而关联子查询就需要循环迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //关联子查询扫描 A 表的每一条记录 rA：扫描 B 表 ， 找到其中的第一条满足 rA 条件的记录 。
显然，关联子查询的扫描成本会高于非关联子查询 。
我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化 ， MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导 。
...
可以看到执行时间变成了 0.67s 。
整理
我们诊断的关键点如下：
\1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息 。
\2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判 。
\3. 我们增加了 hint，指导 MySQL 正确进行优化判断 。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断 。
MySQL查询效率很慢的问题如何分析和解决MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时 。MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长 。另外磁盘 IOPS 也会影响崩溃恢复时间 ， 像这里开发库的 HDD IOPS 较低 ， 因此面对大量的表空间 ， 校验速度就非常缓慢 。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍 。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程 。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0，那么 validate= false，即可以跳过表空间校验 。实际测试的时候设置 innodb_force_recovery =1 ， 也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了 。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患 。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间 。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下 ， 反而更有优势 。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了 。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量 ， 跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长 。而以非 debug 模式运行，则无法修改 validate 变量 ， 想法破灭 。
mysql数据库查询好慢怎么解决一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句
1，slow_query_log
这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句 。
2，long_query_time
当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短 。
3，slow_query_log_file
记录日志的文件名 。
4，log_queries_not_using_indexes
这个参数设置为ON，可以捕获到所有未使用索引的SQL语句 ， 尽管这个SQL语句有可能执行得挺快 。
二、检测mysql中sql语句的效率的方法
1、通过查询日志
（1）、Windows下开启MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上
代码如下
log-slow-queries = F:/MySQL/log/mysqlslowquery 。log
long_query_time = 2
（2）、Linux下启用MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上
代码如下
log-slow-queries=/data/mysqldata/slowquery 。log
long_query_time=2
说明
log-slow-queries = F:/MySQL/log/mysqlslowquery 。
为慢查询日志存放的位置，一般这个目录要有MySQL的运行帐号的可写权限，一般都将这个目录设置为MySQL的数据存放目录；
long_query_time=2中的2表示查询超过两秒才记录；
2.show processlist 命令
SHOW PROCESSLIST显示哪些线程正在运行 。您也可以使用mysqladmin processlist语句得到此信息 。
各列的含义和用途：
ID列
一个标识 ， 你要kill一个语句的时候很有用，用命令杀掉此查询 /*/mysqladmin kill 进程号 。
user列
显示单前用户，如果不是root ， 这个命令就只显示你权限范围内的sql语句 。
host列
显示这个语句是从哪个ip的哪个端口上发出的 。用于追踪出问题语句的用户 。
db列
显示这个进程目前连接的是哪个数据库 。
command列
显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect） 。
time列
此这个状态持续的时间，单位是秒 。
state列
显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个 sql语句 ， 以查询为例 ， 可能需要经过copying to tmp table ， Sorting result，Sending data等状态才可以完成
【mysql查询怎么那么难 mysql 查询很慢原因】info列
显示这个sql语句，因为长度有限，所以长的sql语句就显示不全，但是一个判断问题语句的重要依据 。
这个命令中最关键的就是state列，mysql列出的状态主要有以下几种：
Checking table
　正在检查数据表（这是自动的） 。
Closing tables
　正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表 。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中 。
Connect Out
　复制从服务器正在连接主服务器 。
Copying to tmp table on disk
　由于临时结果集大于tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存 。
Creating tmp table
　正在创建临时表以存放部分查询结果 。
deleting from main table
　服务器正在执行多表删除中的第一部分，刚删除第一个表 。
deleting from reference tables
　服务器正在执行多表删除中的第二部分，正在删除其他表的记录 。
Flushing tables
　正在执行FLUSH TABLES ， 等待其他线程关闭数据表 。
Killed
　发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求 。MySQL会在每次的主循环中检查kill标志位 ， 不过有些情况下该线程可能会过一小段才能死掉 。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效 。
Locked
　被其他查询锁住了 。
Sending data
　正在处理SELECT查询的记录，同时正在把结果发送给客户端 。
Sorting for group
　正在为GROUP BY做排序 。
　Sorting for order
　正在为ORDER BY做排序 。
Opening tables
　这个过程应该会很快 ， 除非受到其他因素的干扰 。例如，在执ALTER TABLE或LOCK TABLE语句行完以前，数据表无法被其他线程打开 。正尝试打开一个表 。
Removing duplicates
　正在执行一个SELECT DISTINCT方式的查询 ， 但是MySQL无法在前一个阶段优化掉那些重复的记录 。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端 。
Reopen table
　获得了对一个表的锁 ， 但是必须在表结构修改之后才能获得这个锁 。已经释放锁，关闭数据表，正尝试重新打开数据表 。
Repair by sorting
　修复指令正在排序以创建索引 。
Repair with keycache
　修复指令正在利用索引缓存一个一个地创建新索引 。它会比Repair by sorting慢些 。
Searching rows for update
　正在讲符合条件的记录找出来以备更新 。它必须在UPDATE要修改相关的记录之前就完成了 。
Sleeping
　正在等待客户端发送新请求.
System lock
　正在等待取得一个外部的系统锁 。如果当前没有运行多个mysqld服务器同时请求同一个表 ， 那么可以通过增加--skip-external-locking参数来禁止外部系统锁 。
Upgrading lock
　INSERT DELAYED正在尝试取得一个锁表以插入新记录 。
Updating
　正在搜索匹配的记录，并且修改它们 。
User Lock
　正在等待GET_LOCK() 。
Waiting for tables
　该线程得到通知 ， 数据表结构已经被修改了，需要重新打开数据表以取得新的结构 。然后，为了能的重新打开数据表 ， 必须等到所有其他线程关闭这个表 。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE 。
waiting for handler insert
　INSERT DELAYED已经处理完了所有待处理的插入操作，正在等待新的请求 。
　大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了 ， 需要检查一下 。
　还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着 。
例如如图：
3、explain来了解SQL执行的状态
explain显示了mysql如何使用索引来处理select语句以及连接表 。可以帮助选择更好的索引和写出更优化的查询语句 。
使用方法，在select语句前加上explain就可以了：
例如：
explain select surname,first_name form a,b where a.id=b.id
结果如图
EXPLAIN列的解释
table
显示这一行的数据是关于哪张表的
type
这是重要的列 ， 显示连接使用了何种类型 。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
possible_keys
显示可能应用在这张表中的索引 。如果为空，没有可能的索引 。可以为相关的域从WHERE语句中选择一个合适的语句
key
实际使用的索引 。如果为NULL，则没有使用索引 。很少的情况下，MYSQL会选择优化不足的索引 。这种情况下，可以在SELECT语句 中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len
使用的索引的长度 。在不损失精确性的情况下 ， 长度越短越好
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数
rows
MYSQL认为必须检查的用来返回请求数据的行数
Extra
关于MYSQL如何解析查询的额外信息 。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢
extra列返回的描述的意义
Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
Not exists
MYSQL优化了LEFT JOIN ， 一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
Range checked for each Record（index map:#）
没有找到理想的索引 ， 因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引 ， 并用它来从表中返回行 。这是使用索引的最慢的连接之一
Using filesort
看到这个的时候，查询就需要优化了 。MYSQL需要进行额外的步骤来发现如何对返回的行排序 。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
Using temporary
看到这个的时候，查询需要优化了 。这里 ， MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
Where used
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户 。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）
const
表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引） 。因为只有一行，这个值实际就是常数 ， 因为MYSQL先读这个值然后把它当做常数来对待
eq_ref
在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录 ， 它在查询使用了索引为主键或惟一键的全部时使用
ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生 。对于之前的表的每一个行联合 ， 全部记录都将从表中读出 。这个类型严重依赖于根据索引匹配的记录多少—越少越好
range
这个连接类型使用索引返回一个范围中的行，比如使用或查找东西时发生的情况
index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好 ， 因为索引一般小于表数据）
ALL
这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕 ， 应该尽量避免
如何解决mysql 查询和更新速度慢在做客户关系管理系统的时候遇到联表查询，速度特别慢，导致页面加载时间过长而出现错误 。在上网查询后发现建立索引可以优化查询
在没有建立索引的时候
select c.*,s.* from crm_cu_re c join crm_cu_info s on c.CUS_MAIN_ID=s.CUS_MAIN_ID)
查询结果
(526 row(s) returned)
Total Time: 00:01:15:723
仅仅526条记录?。。〔檠私?6秒?。。。。。。?
尝试建立索引
create index main on crm_custerm_info(CUS_MAIN_ID)；
再次用相同的语句查询
select c.*,s.* fromcrm_cu_re c join crm_cu_info s on _MAIN_ID=s.CUS_MAIN_ID)
查询结果
(526 row(s) returned)
Total Time: 00:00:00:234
同样的526条记录查询花费时间不到1秒?。。⌒侍岣呶奘?。
相同的如果按cus_main_id跟新 crm_cu_info表
在没有建立索引前执行 updatecrm_cu_info set C_NAME ="22"WHERE CUS_MAIN_ID ='xxxxxx'
(1 row(s) affected)
Execution Time : 00:00:00:546
Transfer Time: 00:00:00:000
Total Time: 00:00:00:546
建立索引后 create index main on crm_cu_info(CUS_MAIN_ID)；
(0 row(s) affected)
Execution Time : 00:00:00:000
Transfer Time: 00:00:00:016
Total Time: 00:00:00:016
效率明显提高很多
由此可见索引是快速搜索的关键 。MySQL索引的建立对于MySQL的高效运行是很重要的 。下面几种常见的MySQL索引类型 。
在数据库表中，对字段建立索引可以大大提高查询速度 。假如我们创建了一个 mytable表：
CREATE TABLE mytable(ID INT NOT NULL,username VARCHAR(16) NOT NULL);我们随机向里面插入了10000条记录，其中有一条：5555,admin 。
在查找username="admin"的记录 SELECT * FROMmytable WHERE
username='admin';时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录 。相反，MySQL会扫描
所有记录，即要查询10000条记录 。
索引分单列索引和组合索引 。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引 ， 但这不是组合索引 。组合索引 ， 即一个索包含多个列 。
MySQL索引类型包括：
（1）普通索引
这是最基本的索引，它没有任何限制 。它有以下几种创建方式：
◆创建索引
CREATE INDEX indexName ONmytable(username(length)); 如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同 。
◆修改表结构
ALTER mytable ADD INDEX [indexName] ON(username(length)) ◆创建表的时候直接指定
CREATE TABLE mytable(ID INT NOT NULL,username VARCHAR(16)
NOT NULL,INDEX [indexName] (username(length)));删除索引的语法：
DROP INDEX [indexName] ON mytable;
（2）唯一索引
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值 。如果是组合索引，则列值的组合必须唯一 。它有以下几种创建方式：
◆创建索引
CREATE UNIQUE INDEX indexName ONmytable(username(length)) ◆修改表结构
ALTER mytable ADD UNIQUE [indexName] ON(username(length)) ◆创建表的时候直接指定
CREATE TABLE mytable(ID INT NOT NULL,username VARCHAR(16) NOT NULL,UNIQUE [indexName] (username(length)));
（3）主键索引
它是一种特殊的唯一索引，不允许有空值 。一般是在建表的时候同时创建主键索引：
CREATE TABLE mytable(ID INT NOT NULL,username VARCHAR(16)
NOT NULL,PRIMARY KEY(ID));当然也可以用 ALTER 命令 。记?。阂桓霰碇荒苡幸桓鲋骷?。
（4）组合索引
为了形象地对比单列索引和组合索引，为表添加多个字段：
CREATE TABLE mytable(ID INT NOT NULL,username VARCHAR(16)
NOT NULL,city VARCHAR(50) NOT NULL,age INT NOT NULL);
为了进一步榨取MySQL的效率，就要考虑建立组合索引 。就是将 name, city, age建到一个索引里：
ALTER TABLE mytable ADD INDEX name_city_age(name(10),city,age);
建表时，usernname长度为 16，这里用
10 。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大?。岣逫NSERT的更新速度 。
如果分别在 usernname，city，age上建立单列索引 ， 让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引 。虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引 。
建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：
usernname,city,ageusernname,cityusernname 为什么没有
city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果 。简单的理解就是只从最左面的开始组合 。并不是只要包含这三列的查询都
会用到该组合索引，下面的几个SQL就会用到这个组合索引：
SELECT * FROM mytable WHREEusername="admin" AND city="郑州"SELECT * FROM mytable WHREEusername="admin" 而下面几个则不会用到：
SELECT * FROM mytable WHREE age=20 ANDcity="郑州"SELECT * FROM mytableWHREE city="郑州"
（5）建立索引的时机
到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此 ，
因为MySQL只对，=，=，，=，BETWEEN ， IN，以及某些时候的LIKE才会使用索引 。例如：
SELECT t.NameFROM mytable t LEFT JOIN mytable mON
t.Name=m.username WHERE m.age=20 ANDm.city='郑州'
此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要 。
刚才提到只有某些时候的LIKE才需建立索引 。因为在以通配符%和_开头作查询时，MySQL不会使用索引 。例如下句会使用索引：
SELECT * FROM mytable WHERE usernamelike'admin%' 而下句就不会使用：
SELECT * FROM mytable WHEREt Namelike'璵in' 因此，在使用LIKE时应注意以上的区别 。
（6）索引的不足之处
上面都在说使用索引的好处，但过多的使用索引将会造成滥用 。因此索引也会有它的缺点：
◆虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE 。因为更新表时，MySQL不仅要保存数据 ， 还要保存一下索引文件 。
◆建立索引会占用磁盘空间的索引文件 。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快 。
索引只是提高效率的一个因素，如果你的MySQL有大数据量的表 ， 就需要花时间研究建立最优秀的索引，或优化查询语句 。
（7）使用索引的注意事项
使用索引时，有以下一些技巧和注意事项：
◆索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值 ， 那么这一列对于此复合索引就是无效的 。所以我们在数据库设计时不要让字段的默认值为NULL 。
◆使用短索引
对串列进行索引，如果可能应该指定一个前缀长度 。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引 。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作 。
◆索引列排序
MySQL查询只使用一个索引 ， 因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的 。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引 。
◆like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题 。like “猘%”不会使用索引而like “aaa%”可以使用索引 。
◆不要在列上进行运算
select * from users whereYEAR(adddate)2007; 将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成
select * from users whereadddate‘2007-01-01’;
◆不使用NOT IN和操作
关于mysql查询怎么那么难和mysql 查询很慢原因的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：关于pagestatehtml5的信息

    下一篇：服务器ip端口号 服务器ip后面怎么加端口