有两种启用方式:1, 在my.cnf 里 通过 log-slow-queries[=file_name]
日志就跟人们写的日记一样，记录着过往的事情。但是人的日记是主观的（记自己想记的内容），而数据库的日志是客观的，根据记录内容分为以下好几种日志：
对于数据库来说安装，部署几乎是一次性的。后期的管理和优化是持续性的工作。 对于MySQL来说，可以说90%问题都在SQL语句上面。从问题SQL的筛选和优化，在MySQL环境下常用哪些方式。(以下版本是MySQL8.0.23） MySQL优化前置知识基础
Sql每天都在查，但是sql优化的边界你了解吗？、在一般的认识里数据库就是一个黑箱，我把sql扔进去，它把结果返回来，至于sql优化貌似很遥远的地方，直到系统好慢的时候才会怀疑sql出了毛病。
Mysql慢查询和慢查询日志分析 众所周知，大访问量的情况下，可添加节点或改变架构可有效的缓解数据库压力，不过一切的原点，都是从单台mysql开始的。下面总结一些使用过或者研究过的经验，从配置以及调节索引的方面入手，对mysql进行一些优化。 第一步应该做的就是排查问题，找出瓶颈，所以，先从日志入手 开启慢查询日志 mysql>show variables like “%slow%”; 查看慢查询配置，没有则在my.cnf中添加，如下 log-slow-queries = /data/mysqldata/
随着业务发展，这些表会越来越大，如果处理不当，查询统计的速度也会越来越慢，直到业务无法再容忍。
启用慢查询日志 mysql 中的 slow log 是用来记录执行时间较长(超过 long_query_time 秒)的 sql 的一种日志工具。 启用 slow log 在 my.cnf 中设置 [mysqld] slow_query_log=on slow_query_log_file=mysql-slow 重启 MySQL 服务。 1.工具集 五款常用工具 mysqldumpslow mysqlsla myprofi mysql-explain-slow-log
其实，在写这篇博客之前，我也是感觉自己会点优化，至少知道不要使用“*”号啊，给经常查询的列创建索引啊什么的，其实都不是大家想的那样简单的，其实它们背后存在很多的东西，值得我们去理解和学习。 和大家分享讨论一个问题吧，子查询和连接查询哪一个查询速度快？最重要的目的是能帮助大家在以后的开发路上不要再犯我这种的错误，看到就是赚到，哈哈。 我的答案是连接查询。因为这是我在前几天的实践项目中亲身体会到的，感触颇深，在给我们公司的网站首页执行了一条统计SQL语句，当时我是用子查询写的sql语句，第一次执行了21
Mysql数据库中CASE WHEN语句，是用于计算条件列表并返回多个可能结果表达式之一。
count 计数函数 计算某个字段出现的里面的内容 不为null 就+1
开发人员基本都知道，我们的数据存在数据库中（目前最多的是MySQL和Oracle，由于作者更擅长MySQL，所以这里默认数据库为MySQL），服务器通过sql语句将查询数据的请求传入到MySQL数据库。数据库拿到sql语句以后。都是进行了哪些操作呢？这里向大家介绍下我的个人的理解，欢迎大家评论区批评指正。
工作中经常需要汇总数据而不是将它们全部检索出来（实际数据本身：返回实际数据是对时间和处理资源的浪费），这种类型的检索有以下特点：
MySQL中的聚合函数用于对数据进行计算和统计，常见的聚合函数包括下面列举出来的聚合函数：
5.合理创建联合索引（避免冗余），(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c)
当数据量比较大，若SQL语句写的不合适，会导致SQL的执行效率低，我们需要等待很长时间才能拿到结果
从4到1，成本是逐渐增大的，因此数据库的优化上，SQL语句优化是很重要的一个方面。
对数据库中的记录依据某个字段进行排序是一种常见需求，虽然简单的Order by可以胜任，但如果想要输出具体的排名却难以直接实现。如果再考虑重复排名或者分类排名，那么情况就更为复杂。
2、 数据库命名规范，统一：hs_xxxx；表名不超过40个字符（即最大只能40个字符）
Spark SQL SparkSQL的前身是Shark，它抛弃原有Shark的代码,汲取了Shark的一些优点,如内存列存储(In-Memory Columnar Storage)、Hive兼容性等,重新开发了SparkSQL代码;由于摆脱了对Hive的依赖性,SparkSQL无论在数据兼容、性能优化、组件扩展方面都得到了极大的方便。 1、Spark SQL性能 Spark SQL比hive快10-100倍，原因： 内存列存储( In- Memory Columnar Storage ) 基于Row的J
日常的应用开发中可能需要优化SQL，提高数据访问和应用响应的效率，不同的SQL，优化的具体方案可能会有所不同，但是路径上，还是存在一些共性的。碰巧看到杨老师的这篇文章《第45期：一条 SQL 语句优化的基本思路》，为我们优化一些MySQL数据库的SQL语句提供了可借鉴的路径，值得参考和应用。
目前，Hive底层使用MapReduce作为实际计算框架，SQL的交互方式隐藏了大部分MapReduce的细节。这种细节的隐藏在带来便利性的同时，也对计算作业的调优带来了一定的难度。未经优化的SQL语句转化后的MapReduce作业，它的运行效率可能大大低于用户的预期。本文我们就来分析一个简单语句的优化过程。
mysql中可以使用explain这个关键字来获取（查询）sql语句的查询执行计划的。使用explain关键字，可以模拟mysql优化器执行的sql语句，从而知道mysql是如何处理sql语句的。通过explain可以分析查询语句或表结构的性能瓶颈。
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
今天给大家分享mysql常用的服务器状态命令 ，希望对大家日常运维mysql数据库或者调优提供一些帮助！
Mysql数据库是一个基于结构化数据的开源数据库。SQL语句是MySQL数据库中核心语言。不过在MySQL数据库中执行SQL语句，需要小心两个陷阱。 陷阱一：空值不一定为空 空值是一个比较特殊的字段。在MySQL数据库中，在不同的情形下，空值往往代表不同的含义。这是MySQL数据库的一种特性。如在普通的字段中(字符型的数据)，空值就是表示空值。但是如果将一个空值的数据插入到TimesTamp类型的字段中，空值就不一定为空。此时为出现什么情况呢 我先创建了一个表。在这个表中有两个字段：User_i
如果觉得老调不好，可以DruidDataSource dataSource = new DruidDataSource(); 再调用setter方法使用配置文件的值，不过很麻烦。
方法一： 全局变量设置，将 slow_query_log 全局变量设置为“ON”状态 mysql> set global slow_query_log='ON'; 设置慢查询日志存放的位置 mysql> set global slow_query_log_file='/usr/local/mysql/data/slow.log'; 查询超过1秒就记录 mysql> set global long_query_time=1;
“SQL语句详细信息”提供冻结或解冻查询计划的按钮。 它还提供了一个Clear SQL Statistics按钮来清除性能统计，一个Export按钮来将一个或多个SQL语句导出到一个文件，以及一个Refresh和Close页面按钮。
墨墨导读：MySQL 8.0 新功能直方图，继承于Oracle ，MairaDB的实现方式。本文从MySQL角度解释，直方图是什么。
前一阵在写很多sql及类sql语句，发现自己的记忆力可以说是相当烂了，上午刚查过插入语句怎么写，下午就忘记了需要重新查，，而且隐隐约约的有点强迫症？？只要记得不是特别清晰，就需要去重新查，看，记一遍，十分浪费时间，因此在这里将自己用到的sql语句记下来，方便后续的查找！！
嵌套查询 用一条SQL语句得结果作为另外一条SQL语句得条件，效率不好把握 SELECT * FROM A WHERE id IN (SELECT id FROM B)
我们生活在数据的黄金时代。有些公司将其分析为更好的自己，有些公司为了获利而进行交易，没有一家公司因其价值而自由放弃 - 对于他们的业务和犯罪分子。
数据库查询相信很多人都不陌生，所有经常有人调侃程序员就是CRUD专员，这所谓的CRUD指的就是数据库的增删改查。
ps：注意拿数据的时候，fetchone、fetchall、fetchmany类似光标移动，取到末尾就没得取了，再取会出问题；
SQL常见面试题总结 （原创不易，你们对阿超的赞就是阿超持续更新的动力！） （以免丢失，建议收藏，阿超持续更新中......） （------------------------------------------------------------------------） 常用SQL语句 SQL常用的聚合函数 Group By和Order By where和having子句的区别 count(*)和count(1)有什么区别 count(1) 含义 用count对字段为null的数据可以查出来吗
在他们的技术咨询生涯中，最常碰到的三个性能相关的服务请求是：如何确认服务器是否达到了性能最佳的状态、找出某条语句为什么执行不够快，以及诊断被用户描述成“停顿”、“堆积”或“卡死”的某些间歇性疑难杂症。
在上一篇《InnoDB 层系统字典表|全方位认识 information_schema》中，我们详细介绍了InnoDB层的系统字典表，本期我们将为大家带来系列第六篇《InnoDB 层锁、事务、统计信息字典表|全方位认识 information_schema》
在上一篇 《配置详解 | performance_schema全方位介绍》 中，我们详细介绍了performance_schema的配置表，坚持读完的是真爱，也恭喜大家翻过了一座火焰山。相信有不少人读完之后，已经迫不及待的想要跃跃欲试了，今天将带领大家一起踏上系列第三篇的征程(全系共7个篇章)，在这一期里，我们将为大家全面讲解performance_schema中事件原始记录表。下面，请跟随我们一起开始performance_schema系统的学习之旅吧。
分页查询是最常用的场景之一，但也通常也是最容易出问题的地方。比如对于下面简单的语句，一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。
SQL 语句优化是一个既熟悉又陌生的话题。面对千奇百怪的 SQL 语句，虽然数据库本身对 SQL 语句的优化一直在持续改进、提升，但是我们不能完全依赖数据库，应该在给到数据库之前就替它做好各种准备工作，这样才能让数据库来有精力做它自己擅长的事情。
索引管理 索引是什么？ 索引就好比一本书的目录，它会让你更快的找到内容； 让获取的数据更有目的性，从而提高数据库检索数据的性能； 索引建立在表的列上(字段)。 索引的设计理念 数据库索引的设计原则：
在应用的的开发过程中，由于初期数据量小，开发人员写 SQL 语句时更重视功能上的实现，但是
千万级大表如何优化，这是一个很有技术含量的问题，通常我们的直觉思维都会跳转到拆分或者数据分区，在此我想做一些补充和梳理，想和大家做一些这方面的经验总结，也欢迎大家提出建议。
优化SQL，是DBA常见的工作之一。如何高效、快速地优化一条语句，是每个DBA经常要面对的一个问题。在日常的优化工作中，我发现有很多操作是在优化过程中必不可少的步骤。然而这些步骤重复性的执行，又会耗费DBA很多精力。于是萌发了自己编写小工具，提高优化效率的想法。
我们都知道，在关系型数据库中，索引的存在是非常重要的，但是不合理的索引反而会影响到业务的性能，那怎么才能合理的设计索引也是业务高效访问数据库需要考虑的？如何才能评估索引创建的合理呢？今天我们给出其中一个评估指标：Cardinality
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
