sql优化

推荐用mixed，默认使用statement，基于上下文。 MySQL Replication复制可以是基于一条语句(Statement level)，也可以是基于一条记录(Row level)，可以在MySQL的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。 Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。 优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。 缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件(MySQL以事件的形式来记录bin-log日志)

目录 一、优化概述 二、查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三、配置优化 1) max_connections 2) back_log 3) interactive_timeout 4) key_buffer_size 5) query_cache_size 6) record_buffer_size 7) read_rnd_buffer_size 8) sort_buffer_size 9) join_buffer_size 10) table_cache 11) max_heap_table_size 12) tmp_table_size 13) thread_cache_size 14) thread_concurrency 15) wait_timeout 一、 优化概述 MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈，CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘I/O瓶颈发生在装入数据远大于内存容量的时候，如果应用分布在网络上，那么查询量相当大的时候那么平瓶颈就会出现在网络上，我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态。 除了服务器硬件的性能瓶颈，对于MySQL系统本身，我们可以使用工具来优化数据库的性能

MySQL是一个强大的开源数据库。随着MySQL上的应用越来越多，MySQL逐渐遇到了瓶颈。这里提供 101 条优化 MySQL 的建议。有些技巧适合特定的安装环境，但是思路是相通的。我已经将它们分成了几类以帮助你理解。 MySQL监控 MySQL服务器硬件和OS（操作系统）调优： 1、有足够的物理内存，能将整个InnoDB文件加载到内存里 —— 如果访问的文件在内存里，而不是在磁盘上，InnoDB会快很多。 2、全力避免 Swap 操作 — 交换（swapping）是从磁盘读取数据，所以会很慢。 3、使用电池供电的RAM（Battery-Backed RAM）。 4、使用一个高级磁盘阵列 — 最好是 RAID10 或者更高。 5、避免使用RAID5 — 和校验需要确保完整性，开销很高。 6、将你的操作系统和数据分开，不仅仅是逻辑上要分开，物理上也要分开 — 操作系统的读写开销会影响数据库的性能。 7、将临时文件和复制日志与数据文件分开 — 后台的写操作影响数据库从磁盘文件的读写操作。 8、更多的磁盘空间等于更高的速度。 9、磁盘速度越快越好。 10、SAS优于SATA。 11、小磁盘的速度比大磁盘的更快，尤其是在 RAID 中。 12、使用电池供电的缓存 RAID（Battery-Backed Cache RAID）控制器。 13、避免使用软磁盘阵列。 14. 考虑使用固态IO卡

本文作者：叶金荣，知数堂联合创始人，3306pai社区联合创始人 说说使用腾讯云数据库MySQL和CynosDB的几点感受。 近日对腾讯云旗下的两款数据库产品 云数据库 MySQL (下面称为“标准版MySQL”，产品网址： https://cloud.tencent.com/product/cdb ) 和 MySQL版CynosDB (下面称为“CynosDB MySQL”，产品网址： https://cloud.tencent.com/product/cynosdb ) 做了个小测试，在体验过程中有些个人看法，于是就有了本文。 1. 产品介绍体验 1.1 标准版MySQL 腾讯云数据库 MySQL（TencentDB for MySQL）为用户提供安全可靠，易于维护的数据库服务。MySQL 是世界上最流行的开源关系数据库，通过腾讯云数据库 MySQL，您可实现分钟级别的数据库部署和弹性扩展，不仅经济实惠，而且稳定可靠，易于运维。云数据库 MySQL 提供备份恢复、监控、容灾、快速扩容、数据传输等全套解决方案，为您简化数据库运维工作，使您能更加专注于业务发展。 TXSQL 是腾讯云数据库团队维护的 MySQL 内核分支，100%兼容原生 MySQL 版本。TXSQL 改进了热点更新、隐式锁转换、redo checksum 算法、AHI 锁等，支持并行复制 MTS，支持线程池、加密

Transact-SQL中的存储过程，非常类似于Java语言中的方法，它可以重复调用。当存储过程执行一次后，可以将语句缓存中，这样下次执行的时候直接使用缓存中的语句。这样就可以提高存储过程的性能。 Ø 存储过程的概念 存储过程Procedure是一组为了完成特定功能的SQL语句集合，经编译后存储在数据库中，用户通过指定存储过程的名称并给出参数来执行。 存储过程中可以包含逻辑控制语句和数据操纵语句，它可以接受参数、输出参数、返回单个或多个结果集以及返回值。 由于存储过程在创建时即在数据库服务器上进行了编译并存储在数据库中，所以存储过程运行要比单个的SQL语句块要快。同时由于在调用时只需用提供存储过程名和必要的参数信息，所以在一定程度上也可以减少网络流量、简单网络负担。 1、 存储过程的优点 A、 存储过程允许标准组件式编程 存储过程创建后可以在程序中被多次调用执行，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，但对应用程序源代码却毫无影响，从而极大的提高了程序的可移植性。 B、 存储过程能够实现较快的执行速度 如果某一操作包含大量的T-SQL语句代码，分别被多次执行，那么存储过程要比批处理的执行速度快得多。因为存储过程是预编译的，在首次运行一个存储过程时，查询优化器对其进行分析、优化，并给出最终被存在系统表中的存储计划。而批处理的T

自从两年前了解到的索引以来的，就一直想写一篇有关索引的文章。然而我是个拖延癌症患者，一拖就是两年，不愧是我。该篇文章算是自己的笔记，欢迎批评。 概述 索引是什么？很多书和文章都会使用图书的目录来类比。目录的目的就是用方便我们查找具体内容的位置，具体的章节的范围。与此类似，MySQL中索引的用途是帮助我们加速查询以及排序。 在InnoDB中的索引类型有哈希索引、B+树索引、全文索引。哈希索引在InnoDB中设计为自适应的，不展开讨论。在InnoDB1.12之后有了全文索引，也是应用倒排，还没踩过坑(据说不支持中文)，有时间可以研究一下。 本篇主要讨论B+树索引。 B+树 学习MySQL的索引，必须得先了解其原理，否则很多问题将一头雾水。下文将讲述索引数据结构的原理，而不涉及其复杂的具体实现。 在谈B+树之前，不妨先思考，为什么索引能加快查询？为什么要用B+树作为索引而不用B树？哈希索引查询复杂度为O(1)为什么又不用哈希索引？ BST和AVL 在了解B树和B+树之前，先了解一下二叉搜索树(BST)和平衡二叉树(AVL)。 在顺序存储结构中(如数组)，最快的情况是第一个就是目标值，最坏的情况是最后一个是目标值，假设有n个元素，用大O标记法平均的时间复杂度为O(n)。 使用二叉搜索树可以有效的优化搜索时间。利用二叉搜索树的特性左子节点比父节点小、右子节点比父节点大

MySQL使用INSERT插入多条记录，应该如何操作呢？下面就为您详细介绍 MySQL 使用INSERT插入多条记录的实现方法，供您参考。 看到这个标题也许大家会问，这有什么好说的，调用多次INSERT语句不就可以插入多条记录了吗！但使用这种方法要增加服务器的负荷，因为，执行每一次SQL服务器都要同样对SQL进行分析、优化等操作。幸好MySQL提供了另一种解决方案，就是使用一条INSERT语句来插入多条记录。这并不是标准的SQL语法，因此只能在MySQL中使用。 INSERT INTO users(name, age) VALUES('姚明', 25), ('比尔.盖茨', 50), ('火星人', 600); 上面的INSERT 语句向users表中连续插入了3条记录。值得注意的是，上面的INSERT语句中的VALUES后必须每一条记录的值放到一对(…)中，中间使用","分割。假设有一个表table1 CREATE TABLE table1(n INT)； 如果要向table1中插入5条记录，下面写法是错误的： INSERT INTO table1 (i) VALUES(1,2,3,4,5); MySQL将会抛出下面的错误 ERROR 1136: Column count doesn't match value count at row 1 而正确的写法应该是这样： INSERT

目录 1、使用的表 2、explain 中的列 2.1 id列 1）简单子查询 2）from子句中的子查询 3）union查询 2.2 select_type列 2.3 table列 2.4 type列 2.5 possible_keys列 2.6 key列 2.7 key_len列 2.8 ref列 2.9 rows列 2.10 Extra列 3、索引优化实战 2.1 使用的表 2.2 索引优化原则 EXPLAIN命令（执行计划）是查看优化器如何决定执行查询的主要方法。使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是 如何处理你的SQL语句的，让我们知道 SQL 的执行计划 ，可以帮助我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用，进而分析你的查询语句或是结构的性能瓶颈。 下面是使用 explain 的例子： 在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这条SQL（如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中） 1 、使用的表 DROP TABLE IF EXISTS `actor`; CREATE TABLE `actor` ( `id` int

FLUSH TABLES WITH READ LOCK简称(FTWRL)，该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。 由于FTWRL总共需要持有两把全局的MDL锁，并且还需要关闭所有表对象，因此这个命令的杀伤性很大，执行命令时容易导致库hang住。如果是主库，则业务无法正常访问；如果是备库，则会导致SQL线程卡住，主备延迟。本文将详细介绍FTWRL到底做了什么操作，每个操作的对库的影响，以及操作背后的原因。 FTWRL做了什么操作？ FTWRL主要包括3个步骤： 1.上全局读锁(lock_global_read_lock) 2.清理表缓存(close_cached_tables) 3.上全局COMMIT锁(make_global_read_lock_block_commit) FTWRL每个操作的影响 上全局读锁会导致所有更新操作都会被堵塞；关闭表过程中，如果有大查询导致关闭表等待，那么所有访问这个表的查询和更新都需要等待；上全局COMMIT锁时，会堵塞活跃事务提交。由于FTWRL主要被备份工具使用，后面会详细解释每个步骤的作用，以及存在的必要性。FTWRL中的第1和第3步都是通过MDL锁实现，关于MDL的实现，我之前总结了 MDL锁的文章 ，这里主要介绍清理表缓存的流程。 清理表缓存 每个表在内存中都有一个table_cache

具体报错如下： Table '.\Tablename\posts' is marked as crashed and should be repaired 提示说论坛的帖子表posts被标记有问题，需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下： 找到mysql的安装目录的bin/myisamchk工具，在命令行中输入： myisamchk -c -r ../data/tablename/posts.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql，问题就解决了。 问题分析： 1、 错误产生原因，有网友说是频繁查询和更新dede_archives表造成的索引错误，因为我的页面没有静态生成，而是动态页面，因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏，如：数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 2、问题解决办法。 当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次-