专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

MySQL查询提示

 

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秒,有点得不偿失
  意思是不要为了找方法而花费的时间超过做事情本身的时间

posted on   MSSQL123  阅读(828)  评论(0编辑  收藏  举报

编辑推荐:
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 三行代码完成国际化适配,妙~啊~
· .NET Core 中如何实现缓存的预热?
点击右上角即可分享
微信分享提示