mysql关联查询和查询优化

Mysql索引优化实践进阶 count(1)跟count(字段)执行过程类似,不过count(1)不需要取出字段统计,就用常量1做统计,count(字段)还需要取出字段,所以理论上count(1)比count(字段)会快一点。count(*) 是例外,mysql并不会把全部字段取出来,而是专门做了优化,不取值,按行累加,效率很高,所以不需要用 count(列名)或count(常量)来替代 count(*)。并且 join_buffer 里的数据是无序的,因此对表 t1 中的每一行,都要做 100 次判断,所以内存中的判断次数是。 阅读详情

mysql关联查询

 参考:https://blog.youkuaiyun.com/lu0422/article/details/78892497

mysql查询慢的原因

  • 记录慢查询日志
    分析查询日志,不要直接打开慢查询日志进行分析,这样比较浪费时间和经历,可以使用pt-query-digest工具进行分析
  • 使用show profile
    set profileing = 1;开启,服务器上执行所有语句会检测消耗的时间,存到临时表中
    show profiles
    show profile for query Query_ID

 show profiles  查看所有查询消耗 的时间

show profile for query Query_ID   查看某一条语句查询的具体消耗时间;

  • 使用show status
    show status会返回一些计数器,show global status 查看服务器级别的所有计数
    有时根据这些计数,可以猜测出那些操作代价较高或消耗时间多
  • show processlist
    观察是否有大量线程处于不正常的状态或特征
  • explain
    分析单条的SQL语句

  

mysql查询优化的方式

  • 访问数据太多会导致查询性能下降(不要用select *)
    • 确定MySQL服务器是否在分析大量不必要的数据行
    • 确定应用程序是否在检索大量超过需要的数据,可能是太多行或列
    • 避免使用如下SQL语句
      • 查询不需要的数据,使用limit解决
      • 所表关联返回全部列,制定A.id,A.name,B.age
      • 总是取出全部列,SELECT * 会让优化器无法完成索引覆盖扫描的优化
      • 重复查询相同的数据,可以缓存数据,下次直接读取缓存
    • 是否在扫描额外的记录
      • 使用explain来进行分析,如果发现查询需要扫描大量的数据但是只返回少数行可以用如下技巧去优化:
        • 使用索引覆盖扫描,把所有用的列都放在索引中,这样存储引擎不需要回表获取对应行就可以返回结果
        • 改变数据库的表的结构,修改数据表范式(如果经常需要关联查询,可将另一张表的字段冗余地存储在要查询的表中,以空间换取时间)
        • 重写SQL语句,让优化器可以以更优的方式执行查询
  • 优化长难的查询语句
    • 切分查询
      将一个大的查询分为多个小的相同的查询
    • 分解关联查询
      可以将一条关联查询分解成多条SQL来执行,可以让缓存的效率更高,执行单个查询可以减少锁的竞争,在应用层做关联可以更容易对数据进行拆分,查询效率会有大幅提升,较少冗余记录的查询
  • 优化特定类型的查询语句
    • 优化count()查询
      • count(*)中的*会忽略所有的列,直接统计所有列数,因此不要使用count(列名)
      • MyISAM中,没有任何WHERE条件的count(*)非常快,当有WHERE条件时,MyISAM的count统计不一定比其他表引擎快
      • 可以使用explain查询近似值,用近似值代替count(*)
      • 增加汇总表
      • 使用缓存
    • 优化关联查询
      • 确定ON 或者 USING子句的列上有索引

        Mysql 中联接SQL语句中,ON子句的语法格式为:table1.column_name = table2.column_name。
        当模式设计对联接表的列采用了相同的命名样式时,就可以使用 USING 语法来简化 ON 语法,格式为:USING(column_name)。

      • 确保GROUP BY 和 ORDER BY中只有一个表中的列,这样MySQL才能使用索引
    • 优化子查询
      • 用关联查询替代
    • 优化GROUP BY 和 DISTINCT
      • 这两种查询均可以使用索引来优化,是最有效的优化方法
      • 关联查询中,使用表示列进行分组的效率会更高(尽量使用主键、自增列等)
      • 如果不需要ORDER BY ,进行GROUP BY 时使用ORDER BY NULL ,mysql不会再进行文件排序
    • 优化LIMIT分页
      • LIMIT偏移量大时,查询效率低
      • 可以记录上次查询的最大ID,下次查询时直接根据该ID来查询
    • 优化UNION查询
      • UNION ALL查询效率高于UNION

引用的连接:https://www.cnblogs.com/clannadxr/p/7806090.html

引用的连接:https://blog.youkuaiyun.com/qq_35571554/article/details/82800463

 

《大明王朝1566》中,朝廷财政危机无法解决的根源分析 财政困局中的财富最终流向三重黑洞:​皇室挥霍​(如嘉靖炼丹修殿)、特权阶层贪腐​(严党年入百万两盐税)、制度性损耗​(宗室供养、低效官僚)。更深层的“钱”其实是被禁锢在道德化治理的牢笼中——当国家用“黄河长江皆可为用”的权术思维替代制度性改革时,财政危机便成为帝制王朝无法逃脱的宿命。 阅读详情

相关推荐

深入解析TOM模块的PWM输出与ADC触发机制:从配置到DMA数据传输

本文深入解析了TOM模块在嵌入式系统中的核心应用,详细阐述了如何配置其PWM输出功能,并实现与ADC模块的硬件触发同步。重点介绍了通过DMA机制高效传输ADC采样数据的完整流程,涵盖时钟配置、工作模式选择、引脚映射及联调实战,为电机控制、数字电源等实时系统提供了一套硬件自动化的高效解决方案。

weixin_29227585的博客 367

mysql 多表关联查询如何改进

在进行多表关联查询时,可以通过使用正确的连接类型、优化 WHERE 子句、为关联字段创建索引、减少查询的字段、考虑使用分布式查询、尽量避免子查询、优化连接顺序、利用 EXPLAIN 分析查询、分解复杂查询和使用视图或存储过程等方法来提高查询性能。

洪晓鸿 6441

Qlib数据获取避坑指南:从CSV导入到自定义数据源的完整解决方案

本文详细解析了Qlib数据获取的完整解决方案,从CSV导入到自定义数据源,涵盖了股票数据处理的关键技巧和常见陷阱。特别针对Qlib平台的数据格式要求和复权处理提供了实用指南,帮助量化投资者高效整合Wind等第三方数据源,确保数据质量与模型性能。

weixin_29047919的博客 304

MySQL(五)——MySQL索引优化实战(多表联查优化)

MySQL索引优化实战(多表联查优化)

yemuxiaweiliang的博客 4078

当windows安装git时出现以下错误提示

Windows安装Git时出现多个系统配置设置失败错误(exit code 4294967295),提示包括无法设置textconv、LFS过滤器和SSL等配置项。关键问题在于scalar.exe版本不兼容,系统提示"该版本的scalar.exe与你运行的Windows版本不兼容"。解决方案是检查程序版本是否正确,下载与Windows系统兼容的正确版本重新安装即可。

沧澜的博客 1875

树莓派学习系列7——GPIO基础

前言 原来学单片机的时候,就是通过一系列的引脚来控制单片机。终于学到了通过引脚来控制树莓派了。话不多说咱们先来了解基础。

我在等那么一天的博客 1万+

Mysql 多表联查优化

一、尽量避免使用子查询 二、尽量避免在where 字句中对字段进行null值判断,否则将导致引擎放弃使用索引而进行全表扫描 三、in 和 not in 也要尽量避免使用,否则会导致全表扫描(对于连续的字段可以使用between and;也可以使用exists代替in) 四、尽量使用数字型字段,若只含数值信息的字段尽量不要设置为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为迎请在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型二闫只需要比较一次就够了。 五、尽量使用表变量来代替

weixin_55347832的博客 6799

ROS2 Humble + TurtleBot4仿真环境搭建与避坑实战

本文详细介绍了ROS2 Humble与TurtleBot4仿真环境的搭建与避坑实战,包括环境配置、依赖安装、仿真调试和性能优化等关键步骤。通过保姆级教程和实用技巧,帮助开发者快速搭建稳定的机器人仿真环境,提升开发效率。特别推荐使用Ubuntu 22.04原生系统以避免常见问题。

weixin_30897233的博客 399

MySQL 内连接、外连接与索引优化实战

本文介绍了SQL表连接的分类、底层机制及优化方案。表连接分为内连接和外连接(左外、右外、全外),其中外连接明确区分驱动表与被驱动表。底层执行时,驱动表每条记录都会与被驱动表全表匹配,时间复杂度为O(n²)。优化方案包括:1)小表驱动大表减少匹配次数;2)为被驱动表连接字段添加索引,将复杂度降至O(nlogn);3)为WHERE条件字段加索引;4)确保连接字段类型一致避免隐式转换。内连接中,查询优化器会自动选择数据量小的表作为驱动表,建议在数据量大的被驱动表常用字段上建立索引。

m0_70325779的博客 902

基于大语言模型的学术论文阅读辅助分析系统的研究与应用

本文提出了一种基于大语言模型的学术论文阅读辅助分析系统PaperMind,旨在解决传统学术阅读方式面临的三大困境:信息定位困难、跨学科知识断层和手动整理耗时。系统采用检索增强生成(RAG)架构,通过PDF文档解析、语义分割、向量嵌入与FAISS向量检索相结合的技术路线,构建了完整的文档处理流水线。实验结果表明,系统在文档加载分割、向量检索与问答生成环节均达到预期性能指标,检索命中率最高达98%。该系统为学术文献智能化处理提供了可复用的技术方案,有效解决了通用大语言模型在学术场景中的幻觉引用、归因能力不足等问

huanghm88的专栏 93

Spring AI Alibaba实战训练营-14基于A2A协议智能体应用开发指南

本文介绍了基于A2A协议的智能体应用开发流程,主要包括客户端和服务端两个模块的实现。关键技术包括A2A通信协议、Nacos服务发现、Spring AI Alibaba框架和DashScope通义千问API。开发步骤涵盖环境准备(JDK17、Maven、Nacos)、项目创建、依赖配置(重点引入spring-ai-alibaba相关组件)以及Nacos和DashScope的核心配置。整个系统架构采用客户端通过Nacos发现服务端Agent,再调用阿里云AI服务的模式,实现了AI能力的解耦与复用。

program哲学 505

MySQL关联查询如何优化

前面讲了原理,从原理出发,讲一下优化的建议被驱动表的连接字段建立索引,因为建立索引的查询方式是效率最高的。left join 或者 right join 这种外连接的情况,要保证小表(小结果集)作为驱动表,大表(大结果集)作为被驱动表,这样性能更好。在查询字段的话,要避免写出 select * ,而是根据业务需要,需要查询出来的 select 出来就行,因为这些字段也会加入到 join buffer 中,减少额外的内存消耗。能够直接多表关联的尽量直接关联,不用子查询,因为子查询的效率更加低。

清晨qc的博客 2892

AI学习指南RAG篇(19)-API调用与集成

通过上述API调用示例,您可以方便地将RAGFlow与其他系统集成,实现数据集管理、文档处理、会话管理等功能。希望本文的介绍能帮助您更好地理解和使用RAGFlow的API。

俞兆鹏的博客 2545

MySQL高级篇——关联查询和子查询优化

左外连接:优先右表创建索引,连接字段类型要一致、内连接:驱动表由数据量和索引决定、 join语句原理、子查询优化:拆开查询或优化成连接查询

种一棵树最好的时间是十年前,其次是现在 4181

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

MySQL 多表关联查询优化实践和原理解析

MySQL 多表关联查询优化实践和原理解析

kerwin的博客 8708

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

MySQL高级第八篇:关联查询、子查询和排序相关优化

子查询是MySQL的一项重要的功能,可以帮助我们通过一个SQL语句实现比较复杂的查询。但是,子查询的执行效率不高。,即一个SELECT查询的结果作为另一个SELECT语句的条件。,其速度比子查询要快,如果查询中使用索引的话,性能就会更好。在MySQL中,可以使用连接(JOIN)查询来替代子查询。使用子查询可以进行SELECT语句的。大大增加了1O的次数。

I wanna be myself, where I Belong. 2075

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

关联查询和多次查询的点 以及 MySQL慢查询优化 EXPLAIN详解

A,B两个表数据规模十几万,数据规模都不大,单机MySQL够用了,在单机的基础上要关联两表的数据,先说一个极端情况,A,B两个表都没有索引,并且关联是笛卡尔积,那关联结果会爆炸式增长,可能到亿级别,这个时候网络IO成了瓶颈,这个时候两次十万行结果集的拉去可能远小于1次亿级别的结果集的拉取,那么将关联合并拉到service层做更快。但实际业务中一般不会有这么蠢的行为,一般关联会有连接条件,并且连接条...

scofen的博客 4437

Mysql(五)索引优化 常见的分页场景优化技巧 Join关联查询优化 in和exsits优化 count(*)查询优化

前言 常见的分页场景优化技巧: 根据自增且连续的主键排序的分页查询 根据非主键字段排序的分页查询 Join关联查询优化 嵌套循环连接 Nested-Loop Join(NLJ) 算法 基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法 被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join ? 关联sql的优化 straight_join: in和exsits优化 count(*)查询 常见优化方法

T_Antry 2779

MYSQL性能调优06_分页查询优化、JOIN关联查询优化、in和exsits优化、count(*)查询优化

文章目录①. 分页查询优化②. Join关联查询优化③. in和exsits优化④. count(*)查询优化 ①. 分页查询优化 ①. 坏境准备 表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 10 条记录,实际这条 SQL 是先读取 10010 条记录,然后抛弃前 10000 条记录,然后读到后面 10 条想要的数据。因此要查询一张大表比较靠后的数据,执行效率是非常低的 示例表: CREATE TABLE `employees` ( `id` int(1

所得皆惊喜 801

MySQL中的limit的优化延迟关联和边界查询

explain select * from ph_member limit 4000,10 1 SIMPLE ph_member ALL 10705 100 使用时间为0.006s #延迟关联 explain select * from ph_member INNER JOIN (select id from ph_...

wd521521的博客 581

Join关联查询优化

整个过程会读取 t2 表的所有数据(扫描100行),然后遍历这每行数据中字段 a 的值,根据 t2 表中 a 的值索引扫描 t1 表中的对应行(扫描100次 t1 表的索引,1次扫描可以认为最终只扫描 t1 表一行完整数据,也就是总共 t1 表也扫描了100行)。驱动表是 t2,被驱动表是 t1。当使用left join时,左表是驱动表,右表是被驱动表,当使用right join时,右表时驱动表,左表是被驱动表,当使用join时,mysql会选择数据量比较小的表作为驱动表,大表作为被驱动表。

qq_33221273的博客 841

mysql 数据库join关联查询using(xxx)、原理解析和优化

mysql 数据库join关联查询using(xxx)、原理解析和优化,左外,右外关联查询。等效inner join

m0_58441715的博客 527

Join关联查询、in和exists、count()优化

Join关联查询、in和exists、count()优化

Soil_Three_66的博客 983

《深入解析MySQL性能优化:分页查询与关联查询实战技巧》

本文详细介绍了在MySQL中进行分页查询的优化方法,以及如何高效地使用Join进行关联查询。文章通过创建示例表,分析了数据类型和字段长度对查询性能的影响,并提供了实用的优化技巧,帮助读者在实际项目中提升数据库查询效率。

2301_81724645的博客 891

05-Mysql索引优化实战二

在决定哪个表做驱动表的时候,应该是两个表按照各自的条件过滤,过滤完成之后,计算参与 join 的各个字段的总数据量,数据量小的那个表,就是“小表”,应该作为驱动表。

k_aikai的博客 1723

Mysql索引优化实战(二)

所以,在存储数据时,如果存入值小于等于255,如200,虽然超过2位,但是没有超出TINYINT类型长度,所以可以正常保存;当使用left join时,左表是驱动表,右表是被驱动表,当使用right join时,右表时驱动表,左表是被驱动表,当使用join时,mysql会选择数据量比较小的表作为驱动表,大表作为被驱动表。count(*) 是例外,mysql并不会把全部字段取出来,而是专门做了优化,不取值,按行累加,效率很高,所以不需要用count(列名)或count(常量)来替代 count(*)。

EverythingAtOnce的博客 1123
上一篇: mysql索引学习
下一篇: yii2缓存
QinAction
博客等级 码龄11年 20粉丝 66原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值