SQL 语句优化是一个既熟悉又陌生的话题。面对千奇百怪的 SQL 语句，虽然数据库本身对 SQL 语句的优化一直在持续改进、提升，但是我们不能完全依赖数据库，应该在给到数据库之前就替它做好各种准备工作，这样才能让数据库来有精力做它自己擅长的事情。
日常的应用开发中可能需要优化SQL，提高数据访问和应用响应的效率，不同的SQL，优化的具体方案可能会有所不同，但是路径上，还是存在一些共性的。碰巧看到杨老师的这篇文章《第45期：一条 SQL 语句优化的基本思路》，为我们优化一些MySQL数据库的SQL语句提供了可借鉴的路径，值得参考和应用。
两表使用nest loop（以下简称NL）方式进行连接，小表驱动大表效率高，这似乎是大家的共识，但事实上这是有条件的，并不总是成立。这主要看大表扫描关联字段索引后返回多少数据量，是否需要回表，如果大表关联后返回大量数据，然后再回表，这个代价就会很高，大表处于被驱动表的位置可能就不是最佳选择了。
项目中使用mysql作为数据存储，需要定期将库表中的数据按照给定格式生成报表。根据导出周期的不同分为：日报、周报、月报、季报、年报等格式。
每每一些很深刻的优化案例时，就会无比想念Oracle里的优化技巧，因为无论是从工具还是信息，都会丰富许多。
维表关联系列目录: 一、维表服务与Flink异步IO 二、Mysql维表关联：全量加载 三、Hbase维表关联：LRU策略 四、Redis维表关联：实时查询 五、kafka维表关联：广播方式 六、自定义异步查询
在数据库中执行查询（select）在我们工作中是非常常见的，工作中离不开CRUD，在执行查询（select）时，多表关联也非常常见，我们用的也比较多，那么mysql内部是如何执行关联查询的呢？它又做了哪些优化呢？今天我们就来揭开mysql关联查询的神秘面纱。
本周赠书《性能之巅》第2版 前段时间在跟其他公司DBA交流时谈到了mysql跟PG之间在多表关联查询上的一些区别，相比之下mysql只有一种表连接类型:嵌套循环连接(nested-loop)，不支持排序-合并连接(sort-merge join)与散列连接(hash join)，而PG是都支持的，而且mysql是往简单化方向去设计的，如果多个表关联查询（超过3张表）效率上是比不上PG的。 1. 摘要 不超过3层是为了效率。 更通用 ，更好为了分布式做准备。 下面也对mysql多表关联这个特性简单探讨下~
注：同构关联的表出自同一个地方，比如说两张表都来自Oracle数据库；异构关联的表出自不同地方，比如说一张表来自Oracle数据库，一张表来自于MySQL数据库。
今天遇到一个很神奇的现象，在数据库中，相同的执行计划，执行SQL所需要的时间相差很大，执行快的SQL瞬间出结果，执行慢的SQL要几十秒才出结果，一度让我怀疑是数据库抽风了，后面才发现是见识不足，又进入了知识空白区。
前段时间在跟其他公司DBA交流时谈到了mysql跟PG之间在多表关联查询上的一些区别，相比之下mysql只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)，而PG是都支持的，而且mysql是往简单化方向去设计的，如果多个表关联查询（超过3张表）效率上是比不上PG的。
SQL结构化查询语言(Structured Query Language)，一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
本章讨论存储的程序和视图，这些数据库对象是根据存储在服务器上供以后执行的SQL代码定义的数据库对象。
维表关联是离线计算或者实时计算里面常见的一种处理逻辑，常常用于字段补齐、规则过滤等，一般情况下维表数据放在MySql等数据库里面，对于离线计算直接通过ETL方式加载到Hive表中，然后通过sql方式关联查询即可，但是对于实时计算中Flink、SparkStreaming的表都是抽象的、虚拟的表，那么就没法使用加载方式完成。透过维表服务系列里面讲到的维表关联都是使用编码方式完成，使用Map或者AsyncIO方式完成，但是这种硬编码方式开发效率很低，特别是在实时数仓里面，我们希望能够使用跟离线一样sql方式完成维表关联操作。
本文将和大家分享 MySQL 更新语句的一些小众语法，及笔者在使用多表关联更新遇到的一些问题。
在数据库的运维工作中，如果有一种运筹帷幄的感觉，那么其中一种方式就是看报表，比如喝着咖啡缓缓打开电脑，几十台，上百台的机器的负载明细都在眼底。如果某个地方出现了异常或者明显的抖动，在报表中也能够很清晰的显示出来。 目前这种情况还是很难实现，但是我们可以创造，之前的博文中也分析过了zabbix+orabbix的监控方式，还是存在很多亮点，在监控和定制功能上确实很强大，gc功能本身就很强大，但是扩展相对还是比较困难的。 首先我们来show一个概览图，这个是我们努力的目标。比如我们有几十台DB服务器，在开始工作前
前段时间笔者开发某个项目遇到了MySQL性能问题，每张表的数据量都在五千万以上，个别表数据量甚至在一个亿以上，在开发的过程中遇到了非常多的数据库性能优化难点，笔者在开发过程中查询了很多资料，很多查询语句也在优化过程中取得了比较好的效果。笔者也将开发过程中遇到的sql优化问题总结为文章，以便日后回顾。这篇文章主要讲解mysql执行联结运算的原理。为了避免泄露公司业务及数据，在文章中涉及的sql语句都和公司业务无关。
如何在多表关联场景下合理利用分区表来提升查询性能？基于前几篇关于分区表的介绍，想必大家对 MySQL 分区表的认知已经非常全面：分区表存在的目的就是为了减少每次检索的数据量从而提升整体性能。
当需要查询两个表的交集、并集等数据时，除了嵌套子查询的方式外，还可以使用join的方式提升性能。对于MySQL的join语句，需要两个最基础的“角色”：主表即驱动表，关联表即驱动表。join描述的就是驱动表与被驱动表的关联关系。MySQL有三种关联逻辑处理策略，分别为：Index Nested-Loop Join、Simple Nested-Loop Join、Block Nested-Loop Join。在编写SQL时，需要配合explain使语句选择性能最优的策略。
前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢，影响业务流程。本文从SQL角度进行数据库优化，提升SQL运行效率。
利用 pymysql.connect 建立数据库连接并执行 SQL 命令（需要提前搭建好数据库）：
上两篇文章我们说到MySQL优化回表的三种方式：索引条件下推ICP、多范围读取MRR与覆盖索引
select查询优化一直是日常开发和数据库运维绕不开的一道坎，SQL的查询速度决定了页面的加载速度，进一步决定了客户浏览体验。
最近公司项目添加新功能，上线后发现有些功能的列表查询时间很久。原因是新功能用到旧功能的接口，而这些旧接口的 SQL 查询语句关联5,6张表且编写不够规范，导致 MySQL 在执行 SQL 语句时索引失效，进行全表扫描。原本负责优化的同事有事请假回家，因此优化查询数据的问题落在笔者手中。笔者在查阅网上 SQL 优化的资料后成功解决了问题，在此从==全局角度==记录和总结 MySQL 查询优化相关技巧。
答: • 支持 SQL 92 标准； • 支持 Mysql 集群，可以作为 Proxy 使用； • 支持 JDBC 连接多数据库； • 支持 NoSQL 数据库； • 支持 galera for mysql 集群，percona-cluster 或者 mariadb cluster，提供高可用性数据分片集群； • 自动故障切换，高可用性； • 支持读写分离，支持 Mysql 双主多从，以及一主多从的模式； • 支持全局表，数据自动分片到多个节点，用于高效表关联查询； • 支持独有的基于 E-R 关系的分片策略，实现了高效的表关联查询； • 支持一致性 Hash 分片，有效解决分片扩容难题； • 多平台支持，部署和实施简单； • 支持 Catelet 开发，类似数据库存储过程，用于跨分片复杂 SQL 的人工智能编码实现，143 行 Demo 完成跨分片的两个表的 JION 查询； • 支持 NIO 与 AIO 两种网络通信机制，Windows 下建议 AIO，Linux 下目前建议 NIO； • 支持 Mysql 存储过程调用； • 以插件方式支持 SQL 拦截和改写； • 支持自增长主键、支持 Oracle 的 Sequence 机制。
今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情，希望文章的这些优化技巧对你有用。
Flink 1.11 引入了 Flink SQL CDC，CDC 能给我们数据和业务间能带来什么变化？本文由 Apache Flink PMC，阿里巴巴技术专家伍翀 (云邪）分享，内容将从传统的数据同步方案，基于 Flink CDC 同步的解决方案以及更多的应用场景和 CDC 未来开发规划等方面进行介绍和演示。
但是小姐姐解释说，查询结果确实“诡异”的多出了184行，问题变的 interesting
这是一个统计类的 SQL，直接执行跑了好几个小时都没有结束，所以暂时不知道实际耗时，因为实在是太久了~
上一节内容学习了关于数据表的基本操作，也就是针对单表的增删改查以及创建和删除，而在实际开发中，往往是多表联合操作，尤其是插入和查询用的最多，而这两步都要经过一个“筛选”的过程，这个过程要根据具体业务逻辑，综合不同的表，查询后决定是否满足插入或其他条件。
刚来的时候还有点不适应，做了几个月之后，就变成了熟练工了，左复制，右粘贴，然后改改就是自己的代码了，生活真美好。
Elasticsearch 是一个强大的工具，尤其在全文检索、实时分析、机器学习、地理数据应用、日志和事件数据分析、安全信息和事件管理等场景有大量的应用。
学习了极客时间MySql课程，做个总结 以一条select语句为例：select * from T where ID=4 ，梳理下执行的流程
前两天在刷朋友圈，看到一个视频号链接，说有个云数仓，比ClickHouse 还快3倍。我就点进去看了，原来是 SelectDB 公司的“为数而生，因云而新” SelectDB 产品发布会。这个发布会上 SelectDB 发布了云数仓产品 SelectDB Cloud。
最后两种语法mysql不支持，但是我们可以用union来联合其他的查询结果来拼凑出最终结果。
本篇的主题是关于数据模型的规范化和反规范化的讨论，其实也是一种常见的维度建模的设计和业务使用便捷性的冲突。
首先问题的背景是一个业务做压力测试，排除了很多的前期问题，使用的最有效手段就是索引，在最后一个环节，问题开始陷入焦灼状态，因为这一条SQL的相关表有16张，而且是在业务环节中频繁调用和引用的逻辑。
注意，类似的问题是业务问题，如果要实际落地分析，需要进一步核实确认当前的数据建模。
explain所有人都应该很熟悉，通过它我们可以知道SQL是如何执行的，虽然不是100%管用，但是至少大多数场景通过explain的输出结果我们能直观的看到执行计划的相关信息。
https://shardingsphere.apache.org/document/5.1.1/cn/features/sharding/concept/inline-expression/
对于很多同学来说，写SQL时的表关联看起来是一件很简单的事情，知道逻辑，有预期的结果，好像没什么特别要注意的，今天在写一条SQL逻辑的时候，觉得对于left join的部分还是存在一些误解。
建表共4张表，分别对应学生信息（Student）、课程信息（Course）、教师信息（Teacher）以及成绩信息（SC）
0x00 前言 本篇的主题是关于数据模型的规范化和反规范化的讨论，其实也是一种常见的维度建模的设计和业务使用便捷性的冲突。 0x01 讨论 问题： 在设计数据表的时候，是一个宽表好，还是多个维度表好？ 回答一： 数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题，什么角色使用，怎么保证使用者尽可能好的体验解决问题。从以上所提到的角度去看待问题，拆解以下几点因素： 拆表情况下多张数据表的查询SQL的编写难度有多大，是否会出现为了数据提取需要关联多张
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
