sql优化

https://www.cnblogs.com/hephec/p/4557053.html 曾经偷偷的面试了两个单位，都提到了Mysql的优化问题，所以以后要多多学习数据库的优化知识了。建设数据库的优化大概主要就是索引的优化了吧，因为我们不可能修改数据结构的情况下，提高数据库的查询效率似乎也只能用索引了。当然这也是建立在你sql语句写的比较科学的情况下，如果你的sql语句本身就写的比较垃圾，神仙也救不了你！ 下边是在网上找到的一些资料，保留下来备用吧 1，创建索引 对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 2，复合索引 比如有一条语句是这样的：select * from users where area=’beijing’ and age=22; 如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area

1，创建索引 对 于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索 引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。 但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 2，复合索引 比如有一条语句是这样的：select * from users where area=’beijing’ and age=22; 如 果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率， 但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age, salary)的复合索引，那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引，这被称为最佳左前缀 特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。 3，索引不会包含有NULL值的列 只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值

前言 大家都知道索引对于数据访问的性能有非常关键的作用，都知道索引可以提高数据访问效率。 　　为什么索引能提高数据访问性能?他会不会有“副作用”?是不是索引创建越多，性能就越好?到底该如何设计索引，才能最大限度的发挥其效能? 　　这篇文章主要是带着上面这几个问题来做一个简要的分析，同时排除了业务场景所带来的特殊性，请不要纠结业务场景的影响。 索引为什么能提高数据访问性能? 　　很多人只知道索引能够提高数据库的性能，但并不是特别了解其原理，其实我们可以用一个生活中的示例来理解。 　　我们让一位不太懂计算机的朋友去图书馆确认一本叫做《MySQL性能调优与架构设计》的书是否在藏，这样对他说：“请帮我借一本计算机类的数据库书籍，是属于 MySQL 数据库范畴的，叫做《MySQL性能调优与架构设计》”。朋友会根据所属类别，前往存放“计算机”书籍区域的书架，然后再寻找“数据库”类存放位置，再找到一堆讲述“MySQL”的书籍，最后可能发现目标在藏(也可能已经借出不在书架上)。 　　在这个过程中： “计算机”->“数据库”->“MySQL”->“在藏”->《MySQL性能调优与架构设计》其实就是一个“根据索引查找数据”的典型案例，“计算机”->“数据库”->“MySQL”->“在藏” 就是朋友查找书籍的索引。 　　假设没有这个索引，那查找这本书的过程会变成怎样呢

mysql 大数据分页和索引使用 使用覆盖索引 一个表建立在id,create_time上建立了索引。 如下2个sql语句，执行时间一样。 因为查询字段id被索引覆盖。 select id from order_manage where create_time > '2014-01-01' order by create_time desc limit 100000,10 select a.id from order_manage a inner join ( select id from order_manage where create_time > '2014-01-01' order by create_time desc limit 1000,10) b on a.id = b.id 如下2条sql，使用inner join要快一个数量级。 inner join影响结果集仍然是$start +30,但是数据获取的过程（Sending data状态）发生在索引文件中，而不是数据表文件，这样所需要的系统开销就比前一种普通的查询低一个数量级，而主查询的影响结果集只有30条，几乎无开销。但是切记，这里仍然涉及了太多的影响结果集操作 其实也可以分成2条sql语句来做，第一条使用覆盖索引查询出id，在使用in查询出需要的字段数据。 select * from order_manage

　　设计好MySql的索引可以让你的数据库飞起来，大大的提高数据库效率。设计MySql索引的时候有一下几点注意： 　　1,创建索引 　　对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 　　2,复合索引 　　比如有一条语句是这样的：select * from users where area='beijing' and age=22; 　　如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了（area, age, salary）的复合索引，那么其实相当于创建了（area,age,salary）、（area,age）、（area）三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。 　　3

1. Mysql内核 MyISAM和InnoDB内核选型 1. InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 2. InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； 3. InnoDB 是聚集索引，MyISAM 是非聚集索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 4. InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快； 5. InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 如何选择： 1. 是否要支持事务

整理了一些Java方面的架构、面试资料（微服务、集群、分布式、中间件等），有需要的小伙伴可以关注公众号【程序员内点事】，无套路自行领取 更多优选 一口气说出 9种 分布式ID生成方式，面试官有点懵了 3万字总结，Mysql优化之精髓 为了不复制粘贴，我被逼着学会了JAVA爬虫 技术部突然宣布：JAVA开发人员全部要会接口自动化测试框架 Redis 5种数据结构及对应使用场景，全会面试要加分的 写在前边 在家远程办公第三周，快被手机上的消息搞的有些神经质了，生怕错过一条有用的信息，没办法形势如此，公司摇摇欲坠大家也都如履薄冰，毕竟这时候失业有点惨（ 穷怕了 ）。 但就干活来说还是比较清闲的，和在公司上班相比，清闲下来很多碎片时间，可以随意的做点自己喜欢的事情。而且我发现， 人一但闲下来真的是好可怕 ，潜在的才能会全面爆发，我女朋友这个抖音深度患者，一年不做一回饭的主，一周内接连给我做了两顿黑暗料理，烤馒头版“蛋糕”、浆糊版“凉皮”，然后我就与厕所结下来不解之缘。。。 不过，作为一个程序员，我对黑暗料理是不太感兴趣滴，闲下来还是喜欢学习钻研一些新奇的技术， canal 就成了很好的研究对象，一不小心就监控了公司MySQL的一举一动的 一、canal是个啥？ canal 是阿里开发的一款基于数据库增量日志解析，提供增量数据订阅与消费的框架，整个框架纯 JAVA 开发，目前仅支持

一、在结合业务需求时遇到的： 1、创建索引 尽量避免全表扫描，有预想的结合需求建立合适的索引。 1）最先应该想到的是在order by 和 where这两个关键字上建立适当的索引，比如经查使用planName这个字段进行查询计划，那应该在这个字段上建立索引 2）建立索引对于查询的好处是巨大的，但是过多的索引会导致update和insert的速度变慢，因为update和insert有可能会重构索引导致速度变慢，索引一般一张表的索引不宜建太多。 2、避免通过索引字段进行计算 在创表阶段需有预见性的创建索引。因为在where字句中，如果索引列是计算或者函数的一部分，DBMS的优化器将不会使用索引而使用全表查询,函数属于计算的一种,同时如果需要使用到in和exists的情况下，推荐使用EXISTS，因为in不走索引。 二、在开发过程中时遇到的： 1、开发过程中使用where字段的顺序。 DBMS一般采用自下而上的顺序解析where字句，根据这个原理表连接最好写在其他where条件之前，那些可以过滤掉最大数量记录。 2、能用一条SQL语句解决的尽量不要用多条语句，但是如果需要连表，尽量不要超过4张表。 在每次执行SQL的时候，都要建立网络连接、进行权限校验、进行SQL语句的查询优化、发送执行结果，这个过程是非常耗时的，因此应该尽量避免过多的执行SQL语句

转自：http://blog.csdn.net/earbao/article/details/44901061 apache DBUtils是java编程中的数据库操作实用工具，小巧简单实用， 1.对于数据表的读操作，他可以把结果转换成List，Array，Set等java集合，便于程序员操作； 2.对于数据表的写操作，也变得很简单（只需写sql语句） 3.可以使用数据源，使用JNDI， 数据库连接池 等技术来优化性能--重用已经构建好的数据库连接对象，而不像php，asp那样，费时费力的不断重复的构建和析构这样的对象。 DBUtils包括3个包： org.apache.commons.dbutils org.apache.commons.dbutils.handlers org.apache.commons.dbutils.wrappers DBUtils封装了对JDBC的操作，简化了JDBC操作，可以少写代码。 org.apache.commons.dbutils DbUtils 关闭链接等操作 QueryRunner 进行查询的操作 org.apache.commons.dbutils.handlers ArrayHandler ：将ResultSet中第一行的数据转化成 对象数组 ArrayListHandler将ResultSet中所有的数据转化成List

Mysql错误编码和解释表 1.错误消息的组成 一共由三部分组成 mysql数字错误代码，这个数字的mysql的特定值，不可以移植到其它数据库系统。 一个五位长度的sqlstate值，这些值取自ANSI SQL和ODBC，并且更加标准化。并不是所有的MySQL错误号都具有相应的SQLSTATE值。在这些情况下，使用'HY000' （一般错误）。 错误的消息描述 2.一些额外的说明 如果需要错误检查，请使用错误代码，而不是错误消息。 如果数据库管理员更改语言设置，则会影响错误消息的语言。 错误代码在给定的MySQL系列的GA版本中是稳定的。在系列达到GA状态之前，新的代码可能仍在开发中，可能会发生变化。 错误消息信息在share/errmsg-utf8.txt文件中。 %d并分别%s表示数字和字符串，当它们被显示时被替换成Message值。 share/errmsg-utf8.txt中列出的错误值被用来生成的定义 include/mysqld_error.h和 include/mysqld_ername.hMySQL的源文件。 share/errmsg-utf8.txt列出的SQLSTATE值用于生成include/sql_state.hMySQL源文件中的定义 。 3.错误码和解释 错误：1000SQLSTATE： （） HY000 ER_HASHCHK 消息：hashchk 错误