mysql排序

1、问题描述 在MySQL中我们通常会采用limit来进行翻页查询，比如limit(0,10)表示列出第一页的10条数据，limit(10,10)表示列出第二页。但是，当limit遇到order by的时候，可能会出现翻到第二页的时候，竟然又出现了第一页的记录。 SELECT `post_title`, `post_date` FROM post WHERE `post_status` = 'publish' ORDER BY view_count desc LIMIT 5, 5 　　使用上述SQL查询的时候，很有可能出现和LIMIT 0,5相同的某条记录。而如果使用如下方式，则不会出现重复的情况： SELECT * FROM post WHERE post_status = 'publish' ORDER BY view_count desc LIMIT 5, 5 但是，由于post表的字段很多，仅仅希望用这两个字段，不想把post_content也查出来。为了解决这个情况，在ORDER BY后面使用了两个排序条件来解决这个问题，如下： SELECT `post_title`, `post_date` FROM post WHERE `post_status` = 'publish' ORDER BY view_count desc, ID asc LIMIT 5, 5 按理来说

创建 test 测试表 CREATE TABLE `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `c1` varchar(10) DEFAULT NULL, `c2` varchar(10) DEFAULT NULL, `c3` varchar(10) DEFAULT NULL, `c4` varchar(10) DEFAULT NULL, `c5` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_test_c1234` (`c1`,`c2`,`c3`,`c4`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into `test` (`id`, `c1`, `c2`, `c3`, `c4`, `c5`) values('1','a1','a2','a3','a4','a5'); insert into `test` (`id`, `c1`, `c2`, `c3`, `c4`, `c5`) values('2','b1','b2','b3','b4','b5'); insert into `test` (`id`, `c1`, `c2`, `c3`, `c4`, `c5`) values('3','c1','c2','c3',

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

一、SQL执行顺序以及常见SQL的join查询 sql执行顺序 ： 手写 SELECT DISTINCT <select_list> FROM <left table> <join type> JOIN <right_table> ON <join_codition> WHERE <where_condition> HAVING <having_condition> ORDER BY < order_by_condition> LIMIT < limit number> 机读顺序 1 FROM <left_table> 2 ON <join_condition> 3 <join_type> JOIN <right_table> 4 WHERE <where_condition> 5 GROUP BY <group by_list> 6 HAVING <having_condition> 7 SELECT 8 DISTINCT <select_list> 9 ORDER BY <order_by_condition> 10 LIMIT <limit_number> sql机器执行顺序 七种join关系 二、索引 1、什么是索引 索引是帮助MYSQL高效获取数据的数据结构-->排好序的快速查找数据结构 我们平时所说的索引，没有特别指明，都是指B树（多路搜索树，不一定是二叉）

1、MySQL 查询统计数据表行数三种方式：select count(*) 、select count(1) 、select count(具体字段)，三者查询效率是怎么样的呢？ 解答： 在MySQL InnoDB 存储引擎中，count(*) 和count(*) 都是对所有结果进行count。如果有where 子句，则是对所有筛选条件的数据行进行统计；如果没有where子句，则是对数据表的数据行数进行统计。 因此count(*) 和 count(1) 本质上并没有区别，执行的复杂度都是O(N)，也就是采用全表扫描，进行循环+计数的方式进行统计。 如果是MySQL MyISAM 存储引擎，统计数据表的行数只需要O(1)的复杂度，这是因为每张MyISAM的数据表都有一个meta信息存储了row_count值，而一致性则由表级锁来保证，因为InnoDB支持事务，采用行级锁和MVCC机制，所以无法像MyISAM一样，只维护一个row_count变量，因此采用扫描全表，进行循环+计数的方式来完成统计； 在执行过程中，count(*) 和 count(1)执行时间略有差别，不过效率可以基本看成是相等的。 一般情况，三者的执行效率count(1) = count(*) >count(字段)。我们尽量使用count(*),当然如果你知道你要统计的是某个字段的非空数据行数，则另当别论

文章目录 索引 索引原理 索引技巧与注意事项 建立索引的原则 利用索引排序 InnoDB索引模型 联合索引 聚集索引 辅助索引 覆盖索引 索引合并 Cardinality（基数） 查看索引 Cardinality 优化器选择不使用索引的情况 MRR 验证MRR ICP 验证ICP 索引 只有当索引帮助存储引擎快速查找到记录的带来的好处大于其带来的额外工作时，索引才是有效的。对于非常小的表，大部分情况下简单的全表扫描更高效 在一个100w条数据的表中，如果某一列没有添加索引，那么每一句select语句都要随机地逐条扫描100w行数据，每次都要从中寻找0或者更多匹配的行。虽然这些数据最初是按照顺序加载的，但sql也不能理解这种顺序，它必须要处理所有行才能找到匹配的数据。添加索引并不总能自动改善所有类型的SQL查询的性能。有时候执行全表扫描反而更加高效，这取决于所要求的行数。这就是两种不同访问方式的差异，即通过随机IO操作来获取个别行的数据和使用查询索引及有序IO操作来读取所有数据。 索引除了在给定表上限制需要读取的数据外，索引的另一个主要用途就是快捷高效地在相关的表之间做Join操作。在需要Join的列上使用索引可以显著提升性能，并可以在另一个表中快速找到一个匹配的值。 优点 索引大大减少了服务器需要扫描的数据量 索引可以帮助服务器避免排序和临时表 索引可以将随机IO变为顺序IO

查询基础 2.2 算数运算符和比较运算符 2.2.1算数运算符 + - * / 需要注意 NULL 5 + NULL 10 - NULL 1 * NULL 4 / NULL NULL / 9 NULL / 0 以上运算结果全都是NULL,实际上所有包含NULL的运算，结果肯定是NULL。 2.2.2比较运算符 1. 运算符 含义 = 和~相等 <> 和~不相等 >= 大于等于~ > 大于~ < 小于~ <= 小于等于~ 2.对字符串使用不等号时的注意事项 字符串类型的数据原则上按照字典进行排序 例如： 11 > 2 但是 '11'<'2' 3.不能对NULL使用比较运算符 希望选取NULL记录时，需要在条件表达式中使用 IS NULL 运算符；希望选取不是NULL的记录时，需要在条件表达式中使用 IS NOT NULL 运算符。 2.2.3逻辑运算符 1.SQL中的逻辑运算包含对真、假和不确定进行运算的三值逻辑。 运算符 含义 NOT 否定某一条件 AND 并且 OR 或 2.AND优先级高于OR，优先执行OR可以使用括号。 3.三值逻辑中的AND和OR真值表 AND P Q P AND Q 真 真 真 真 假 假 真 不确定 不确定 假 真 假 假 假 假 假 不确定 假 不确定 真 不确定 不确定 假 假 不确定 不确定 不确定 OR P Q P OR Q 真 真 真 真 假

建议先看看 开发人员MySQL调优-实战篇0 让执行的SQL使用索引 虽然DBA给我们建了很多索引，但没有经验的开发人员往往只看表结构，不太关注索引和如何利用索引提高SQL执行速度，下面罗列一些经验，让你写的SQL更加高效的利用索引 在做实验之前最好先想一想索引的数据结构与排序，以及索引工作的方式，才能更快的理解与记住这些点，否则在工作中遇到更复杂的情况，很可能就不会处理了 查询字段与某一个索引的结构完全一致，包括字段和顺序（完全匹配） create index idx_tv_v_user_u_a_g on tb_v_user(user_name,age,gendor); select * from tb_v_user where user_name = '1F7sJ' and age = 44 and gendor = 1; 查询条件与索引的列与顺序完全一致，执行计划扫描类型为ref。有兴趣的同学可以试试分别将user_name、age、gendor查询条件删除，看看执行计划是什么情况 不在列上做任何附加操作，比如加函数 select * from tb_v_user where left(user_name,5) = '1F7sJ' and age=44 and gendor = 1; 这里的SQL和上面的SQL执行结果是一模一样，写法上区别是在user

自从两年前了解到的索引以来的，就一直想写一篇有关索引的文章。然而我是个拖延癌症患者，一拖就是两年，不愧是我。该篇文章算是自己的笔记，欢迎批评。 概述 索引是什么？很多书和文章都会使用图书的目录来类比。目录的目的就是用方便我们查找具体内容的位置，具体的章节的范围。与此类似，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 大数据分页和索引使用 使用覆盖索引 一个表建立在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