博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
MySQL查询提示
阅读量:6801 次
发布时间:2019-06-26

本文共 2092 字,大约阅读时间需要 6 分钟。

 

MySQL查询提示:

1.LOW_PROPRITY,HIGHT_PRIORITY
  作用:指定sql语句的运行优先级,会将加了HIGHT_PROPRITY提示的sql调度到表访问队列的最前面
  限制:仅对表级别的锁的引擎有效(MyISAM引擎),对非表级别的引擎的锁无效,比如innodb引擎
  用法:update test LOW_PROPRITY set name = 'abc' where id = 1

2.DELAYED
  作用:对于Insert或者replace操作,将待写入的数据放入缓冲区,待表空闲的时候再做真正的插入
  限制:存在丢失数据的风险,并非所有引擎都支持DELAYED 操作,mysql5.7似乎并不支持改操作符
  用法:insert DELAYED into test values (1,'aaa')

3.straight_join 强制连接顺序

  作用:强制连接顺序,指定表按照书写的顺序或者前后顺序来关联
  限制:
  用法:1.select * from t1 a straight_join t2 b on a.id= b.id1  固定t1表和t2 表的关联顺序,
     2.select straight_join * from t1 a inner join t2 b on a.id= b.id1 inner join test c on b.id1 = c.id 让查询中所有的表按照书写顺序做关联
4.SQL_SMALL_RESULT 和 SQL_BIG_RESULT
  作用:在处理DISTINCT或者GROUP BY的时候,提示优化器按照较小(内存空间)或者较大(磁盘临时控件)的方式来处理结果集
  限制:仅对select 语句有效
  用法:select SQL_SMALL_RESULT a.id, count(1) from t1 a straight_join t2 b on a.id= b.id1 group by a.id
5.SQL_BUFFER_RESULT
  作用:将查询结果集放入临时表,尽快释放表锁
  限制:
  用法:select SQL_BUFFER_RESULT * from testbak
6. SQL_CACHE和SQL_NO_CACHE
  作用:告诉查询引起是否将结果缓存在查询缓存中
  限制:
  用法:select SQL_NO_CACHE/*SQL_CACHE*/ * from testbak
7.SQL_CALC_FOUND_ROWS
  作用:存在分页的情况下,提示在计算总行的时候忽略分页限制
  限制:
  用法:select SQL_CALC_FOUND_ROWS * from testbak LIMIT 100; --限制为100 页面
     select FOUND_ROWS();--计算上述语句中不加LIMIT 100情况下的总行数
8.FOR UPDATE 和 LOCK IN SHARE MODE
  作用:锁提示
  限制:仅INNODB引起支持这两个提示
  用法:select * from testbak where id = 8888 for update

表锁定:

  lock table t1 read/write;
  SELECT * FROM t1;
  delete from t1;
  unlock tables ;

 

 

 

9.USE INDEX,IGNORE INDEX,FORCE INDEX
  作用:强制索引提示
  用法:select count(1) from testbak USE index(idx_id) ;
     select count(1) from testbak IGNORE index(idx_id) ;
     select count(1) from testbak FORCE index(idx_id) ;
10. optimizer_search_depth
  控制优化器在穷举执行计划时的限度,如果查询长时间处于Statistics状态,那么可以考虑调地次参数
  optimizer_prune_level
  默认打开,让优化器根据需要扫描的行数来决定是否跳过某些执行计划
  optimizer_switch
  包含开启/关闭优化器特性的标志位
  前两个参数可以让优化器在生成执行计划的时候更加灵活,但是有可能错过一些最优化的执行计划,
  比如优化器要花10秒钟找一个“最”优化的执行计划,
  但是可以话3秒钟找一个“次”优化的执行计划,“次”优化的执行计划可以在2秒钟之内完成查询
  这个查询一共花费了3+2=5秒
  但是如果是花10秒钟找一个“最”优化的执行计划,最优化的执行计划需要0.5秒完成查询
  这个查询一共花费了10+0.5+2=10.5秒,有点得不偿失
  意思是不要为了找方法而花费的时间超过做事情本身的时间

转载地址:http://qvuwl.baihongyu.com/

你可能感兴趣的文章
git 在windows下的应用(一) - 本地仓库代码管理
查看>>
符合通用准则(common criteria compliance)
查看>>
APP-V5.0的Sequencer过程
查看>>
IBM X3650 M3服务器上RAID配置实战
查看>>
Objective-C中的@class,SEL和IMP等灵活机制
查看>>
2030中国足球称霸世界
查看>>
工信部:《关于加强电信和互联网行业网络安全工作的指导意见》
查看>>
开源可实现迁移
查看>>
融合式架构Nutanix深入分析一
查看>>
RHEL6.3下配置简单Apache https
查看>>
利用Cocos2dx-3.0新物理特性模拟弹珠迷宫
查看>>
Office 365系列之三:Office365初体验
查看>>
VMware View client for iPad在医疗行业的应用
查看>>
Altiris 7.1 Agent
查看>>
独家爆料:创宇云与小鸟云的故事
查看>>
Windows Server 2012 RMS for Exchange Server 2013
查看>>
Linux网络IP配置
查看>>
FireEye:K3chang行动***欧洲外交部门
查看>>
关于Spring MVC 4,你需要知道的那些事
查看>>
如何远程调试Python代码
查看>>