sql优化

对于数据库，优化查询的方法 1.使用索引 　　使用索引时，应尽量避免全表扫描，首先应考虑在 where 及 order by ，group by 涉及的列上建立索引。 2.优化SQL语句 　 1）分析查询语句：通过对查询语句的分析，可以了解查询语句执行情况，找出查询语句执行的瓶颈，从而优化查询语句。 　　　通过explain（查询优化神器）用来查看SQL语句的执行结果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。 　　　例如：explain select * from news; 　2）任何地方都不要使用select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。 　3）不在索引列做运算或者使用函数。 　4）查询尽可能使用 limit 减少返回的行数，减少数据传输时间和带宽浪费。 3.优化数据库对象 　1）优化表的数据类型 　　使用 procedure analyse()函数对表进行分析，该函数可以对表中列的数据类型提出优化建议。表数据类型第一个原则是：使用能正确地表示和存储数据的最短类型。这样可以减少对磁盘空间、内存、CPU缓存的使用。 　　使用方法：select * from 表名 procedure analyse(); 　2）对表进行拆分 　　通过拆分表可以提高表的访问效率。有两种拆分方法： 　 　a.垂直拆分（按照功能模块） 　　

网络上有很多MySQL表碎片整理的问题，大多数是通过demo一个表然后参考data free来进行碎片整理，这种方式对myisam引擎或者其他引擎可能有效（本人没有做详细的测试）. 对Innodb引擎是不是准确的，或者data free是不是可以参考，还是值得商榷的。 本文基于MySQL的Innodb存储引擎，数据库版本是8.0.18，对碎片（fragment）做一个简单的分析，来说明如何量化表的碎片化程度。 涉及的参数 1，information_schema_stats_expiry information_schema是一个基于共享表空间的虚拟数据库，存储的是一些系统元数据信息，某些系统表的数据并不是实时更新的，具体更新是基于参数information_schema_stats_expiry。 information_schema_stats_expiry默认值是86400秒，也就是24小时，意味着24小时刷新一次information_schema中的数据，做测试的时候可以设置为0，实时刷新information_schema中的元数据信息。 2，innodb_fast_shutdown 因为要基于磁盘做一些统计，需要将缓存或者redo log中的数据在重启实例的时候实时刷入磁盘，这里设置为0，在重启数据库的时候将缓存或者redo log实时写入表的物理文件。 3

1. 优化简介 　　MySQL性能优化包括：查询优化、数据库结构优化、MySQL服务器优化等。 2. 查询优化 2.1 分析查询语句 　　MySQL提供EXPLAIN和DESCRIBE，用来分析查询语句。 　　EXPLAIN语句的基本语法： EXPLAIN [EXTENDED] SELECT select_options 　　其中，EXTENDED用于EXPLAIN产生附加信息，select_options是SELECT语句的查询选项，包括FROM WHERE子句等。 mysql> EXPLAIN SELECT * FROM product; +----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+---------+------------+------+---------------+------+---------+------+-----

/*--> */ /*--> */ 基数评估 目录 基数评估 ... 1 说明 ... 2 基数评估准确的重要性 ... 2 模型假设 ... 3 启用新的基数评估 ... 3 验证基数评估的版本 ... 3 在迁移到新的 基数评估前要测试 ... 4 校验基数评估 ... 4 偏差问题 ... 4 需要手动处理的变化 ... 4 避免因为新的 CE 造成性能下降 ... 4 SQL Server 2014 中的修改 ... 5 增加多个谓词的相关性的假设 ... 5 修改超出统计信息范围的评估 ... 5 Join 评估算法修改 ... 5 Join 包含（ Containment ）假设的修改 ... 6 不同值计数评估的变化 ... 7 诊断输出 ... 7 新基数评估的调优方法 ... 8 修改数据库兼容级别 ... 8 使用跟踪标记 ... 8 基础调优方法 ... 8 说明 查询优化器的目的是为了找出有效的执行计划，根据 cost 运算，取出 cost 最小的计划，作为执行计划。其中影响 cost 最重要的一项就是基数评估（估计行数）。 SQL Server 2014 对基数评估做了修改。 基数评估准确的重要性 基数评估提供以下信息： 1. 响应行数评估（ the distribution of data ） 2. 不同值个数评估（ distinct value

一、LogMiner的用途 日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有 DML 语句。 在 Oracle 8i 之前， Oracle 没有提供任何协助数据库管理员来读取和解释重作日志文件内容的工具。系统出现问题，对于一个普通的数据管理员来讲，唯一可以作的工作就是将所有的 log 文件打包，然后发给 Oracle 公司的技术支持，然后静静地等待 Oracle 公司技术支持给我们最后的答案。然而从 8i 以后， Oracle 提供了这样一个强有力的工具 -LogMiner 。 LogMiner 工具即可以用来分析在线，也可以用来分析离线日志文件，即可以分析本身自己数据库的重作日志文件，也可以用来分析其他数据库的重作日志文件。 总的说来， LogMiner 工具的主要用途有： 1 ．跟踪数据库的变化：可以离线的跟踪数据库的变化，而不会影响在线系统的性能。 2 ．回退数据库的变化：回退特定的变化数据，减少 point-in-time recovery 的执行。 3 ．优化和扩容计划：可通过分析日志文件中的数据以分析数据增长模式。 二、安装LogMiner 要安装 LogMiner 工具，必须首先要运行下面这样两个脚本， 1．$ORACLE_HOME/rdbms/admin/dbmslm.sql 2．$ORACLE_HOME

【问题】 有台MySQL 5.6.21的数据库实例以写入为主，IO %util接近100% 写入IOPS很高 【分析过程】 1、通过iotop工具可以看到当前IO消耗最高的mysql线程 2、查看线程49342的堆栈，可以看到正在进行redo log的刷新，对应的是9号文件 3、9号文件对应的是redo log的第一个文件 为什么mysql进程会频繁的刷新redo log文件，要结合redolog的刷盘策略来分析，关键是innodb_flush_log_at_trx_commit参数， 默认是1，最安全，但在写压力大的情况下，也会带来较大的性能影响，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去。 结合这个集群的写入场景来看，大部分都是小事务的写入，每次事务提交都会触发刷盘动作，这种场景下通过增大innodb_log_buffer_size和innodb_log_file_size的优化效果不明显 【优化方案】 1、应用层面，对于写压力大的系统，可以将单条的insert语句优化为小批量的insert语句，这样事务commit的次数减少，redo log刷盘减少，性能理论上会有提升 2、MySQL层面，对于日志类型的系统，如果允许宕机的情况下少量数据丢失，可以将innodb_flush_log_at_trx

mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 测试实验 1. 直接用limit start, count分页语句， 也是我程序中用的方法： select * from product limit start, count 当起始页较小时，查询没有性能问题，我们分别看下从10， 100， 1000， 10000开始分页的执行时间（每页取20条）， 如下： select * from product limit 10, 20 0.016秒 select * from product limit 100, 20 0.016秒 select * from product limit 1000, 20 0.047秒 select * from product limit 10000, 20 0.094秒 我们已经看出随着起始记录的增加，时间也随着增大， 这说明分页语句limit跟起始页码是有很大关系的，那么我们把起始记录改为40w看下（也就是记录的一般左右） select * from product limit 400000, 20 3.229秒 再看我们取最后一页记录的时间 select * from product limit 866613, 20 37.44秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

原文出处： http://www.cnblogs.com/wy123/p/5933734.html 先看常用的一种表结构设计方式： 那么可能会遇到一种典型的查询方式，主子表关联，查询子表中的某些（或者全部）Key点对应的Value，横向显示（也即以行的方式显示） 这种查询方式很明显的一个却显示多次对字表查询（暂时抛开索引） 相比这种查询方式很多人都遇到过，如果子表是配置信息之类的小表的话，问题不大，如果字表数据量较大，可能就会有影响了。 这个查询目的是将”纵表”存储的结果“横向”显示，相当于横列转换的感觉了。 可以将子表的结果一次性将纵表的结果转换成横标，再跟主表连接， 然后得到一个最终一样的查询结果（格式），就能够减少子表的查询次数 这里将子表的结果“一次性将纵表的结果转换成横标”，是典型的行列转换操作 首先先看一下这里所说的一次转换成横标的这一步骤，需要借助pivot，一步一步来 然后看跟主表join之后，两种查询方式的整体查询结果 那么看一下后一种查询方式也即通过行业转换之后做join的执行计划，可以看到只对字表进行了一次查找（这里是index seek，但是暂抛开索引） 观察一下两条SQL的IO信息，可以发现，前者的Scan count是5，逻辑读是65，后者的Scan count是1，逻辑读是13，65=13*5。可见后者是一次性将表中的几个Key值读取出来的

三 触发器 　　对某个表进行某种操作欠货（如：增删改查），希望触发某个动作，可以使用触发器。 　　1.创建触发器 create trigger trigger1_before_insert_tb1 before insert on tb1 for each row begin ... endbefore可以换成after, insert可以换成delete,update. 　　 　 在想tb1插入数据后，tb2结果： 　　 　　触发器获得用户提交的数据： create trigger tri_after_insert_tb1 after insert on tb1 for each row begin NEW.nid (为用户新提交过来的 tb1.nid的值） NEW.name(为用户新提交过来的tb1.name的值） insert into tb2(num) values(NEW.nid); end create trigger tri_after_delete_tb1 after delete on tb1 for each row begin OLD.nid (为删除的tb1.nid的值） OLD.name(为删除的tb1.name的值） insert into tb2(num) values(OLD.nid); end create trigger tri_after

前言：前面介绍了Java、JVM相关方面的题目，该篇介绍数据库方面相关的题目，这里数据库为MySql，因为笔者或朋友在面试过程中都是涉及MySql的相关知识点。 数据库篇 在数据库题目中，由于现在大部分公司都是使用MySql作为数据库，因此笔者及其朋友所遇到的问题也都是MySql相关的知识点。 1）MySql中索引的基本定义，优劣势，以及索引优化。 索引是帮助Mysql高效获取数据的 数据结构 ，因此，索引的 本质 就是数据结构，索引的目的在于提高 查询 效率，可类比字典。 索引： 排好序的快速查找的数据结构。 用途： 排序 + 快速查找 。注意，是两种功能。 数据库除了存储数据本身之外，还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种 数据结构 就是索引。 MySql索引通常是指 B+树 索引。 索引优势： 类似书籍的目录，提高数据检索的效率，降低数据库的 IO 成本（因为数据最终是存储在 磁盘 上的）。 通过索引列对数据进行排序，降低数据排序的成本，降低了 CPU 的消耗（因为排好序，查询速度增加）。 索引劣势： 索引也是 一张表 ，保存了主键与索引字段，并指向实体表的记录，所以索引列也是要 占用磁盘空间的 。 虽然提高了 查询速度 ，但是会 降低更新速度（因为数据更新后，需要重新对索引排序） ，如