mysql排序

排序查询 语法: select 查询字段1 from 表 where 【筛选条件】 order by 要排序字段2 asc升序、desc 降序，要排字段3 asc升序、desc降序 如果不写默认为升序 案例:查询员工信息，要求工资从高到低排序 SELECT * FROM employees ORDER BY salary DESC; #案例2：查询部门编号>=90，按入职日期升序的员工信息 SELECT * FROM employees WHERE department_id >=90 ORDER BY hiredate ASC; #案例：按表达式排序，如按年薪高低显示年薪 SELECT salary*12*(1+IFNULL(commission_pct,0)) FROM employees ORDER BY salary*12*(1+IFNULL(commission_pct,0)) DESC; #案例:将排序字段起别名，再将按别名排序 SELECT salary*12*(1+IFNULL(commission_pct,0)) AS 年薪 FROM employees ORDER BY 年薪 ASC; #案例:按姓名的长度降序显示员工的姓名和工资（按函数排序） SELECT LENGTH('aaaa'); #显示长度为4 SELECT LENGTH(last_name) AS

手动控制排序使用 Django update方法，所有涉及的数据每一条都会执行一次SQL update语句，MySQL有case语句可将所有影响的数据进行一次性更改，查看Django文档支持case语句 https://docs.djangoproject.com/en/2.2/ref/models/conditional-expressions/ >>> a_month_ago = date.today() - timedelta(days=30) >>> a_year_ago = date.today() - timedelta(days=365) >>> # Update the account_type for each Client from the registration date >>> Client.objects.update( ... account_type=Case( ... When(registered_on__lte=a_year_ago, ... then=Value(Client.PLATINUM)), ... When(registered_on__lte=a_month_ago, ... then=Value(Client.GOLD)), ... default=Value(Client.REGULAR) ... ), ... ) >>>

摘要 为了学习研究MySQL数据库在工作原理，深刻理解MySQL在企业运用时如何保证其高效运行。分别从表结构的优化，SQL语句的优化，存储引擎的选择，索引的优化以及现今MySQL的发展与其他企业级数据库的比较。介绍了从编码选择到数据类型的选择以及从整体的角度设计表结构。在SQL语句的选择和使用的介绍的时候，深入介绍了一些基本的使用原则以及在一般在使用过程中我们存在的误区以及如何解决这些问题。着重介绍了MySQL的几个存储引擎MyISAM、InnoDB和NDBCluster的差异以及各自的适用范围。有介绍了MySQL的索引的一些优化的建议以及高屋建瓴地阐述和比较了MySQL的优劣和发展态势。 前言 数据库作为应用作为广泛，地位极为重要的中间件应用，学习和使用数据库管理系统变得越来越重要。为了研究和总结对mysql数据库的学习结果，特别从数据表结构、sql语句优化、存储引擎的选择、索引的应用、以及mysql的比较总结对mysql技术做了一个比较全面升入的介绍。使用mysql的过程中，如何更好地使用与优化越来越重要，在这篇文章中就阐述。 第一章 表结构的优化 数据表是数据库的具体表现形式，设计优良的数据库拥有良好的表结构，者不单单指数据库的表需要满足范式结构，为了更有利于具体操作，表结构还需要实际的可扩展性，以便于做增删改查，又需要根据数据表的具体作用做出调节

1. 索引的本质 　　MySQL官方对索引的定义为：索引是帮助MySQL高效获取数据的数据结构。 　　数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度尽可能的快，因此 数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法是顺序查找（liner search），这种复杂度为o(n)的算法在数据量大时，速度很慢。但是我们有更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果稍微分析一下会发现，每种查找算法都只能用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉查找只能应用于二叉查找树上，但是数据本身的组织结构不可能满足各种数据结构（例如，一般不可能同时将两列都按顺序进行组织），所以在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实训高级查找算法。这种数据结构，就是索引。 　　为了加快查询速度，可以维护一个二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在o(logN)的复杂度内获取到相应数据。 　　虽然这是一个货真价实的索引，但是实际的数据库系统几乎没有使用二叉查找树实现的。。。 二叉排序树 　　二叉排序树的排序规则如下： 　　1）若左子树不空

关于数据库排序查询简单总结 CREATE TABLE TEST_LY( ID NUMBER(4), A NUMBER(2), B NUMBER(2) ); INSERT INTO TEST_LY VALUES(1,1,2); INSERT INTO TEST_LY VALUES(2,3,1); INSERT INTO TEST_LY VALUES(3,1,3); INSERT INTO TEST_LY VALUES(4,3,2); INSERT INTO TEST_LY VALUES(5,1,5); INSERT INTO TEST_LY VALUES(6,1,2); INSERT INTO TEST_LY VALUES(7,4,-1); INSERT INTO TEST_LY VALUES(8,1,2); COMMIT; 当在查询时候出现排序需求是可考虑从这几方面设计查询语句。 1，使用order by 排序。 select * from test_ly order by id;默认是升序排列 select * from test_ly order by id Desc ；降序排列。 select * from test_ly order by id Asc ；升序排列。 2，union 也具有排序功能 SELECT * FROM TEST_LY WHERE A=1 OR B=2

mysql 查询结果如果不给予指定的order by ,那么mysql会按照主键顺序（innodb引擎）对结果集加以排序，那么最后的排序可能就不是你想要的排序结果。 举个例子，我要按照前端传过来的mongoId集合来查询数据库并且返回同样排序的结果集合，如（M3,M5,M4），他们对应的主键顺序为（M4,M3,M5）。如果在查询语句中不加order by 对查询结果排序，那么结果就会变成主键顺序（M4,M3,M5）。 就像上图，最后的结果是按VId排的序。那么如果想要按照（M3,M5,M4）的排序返回结果，就需要用到自排序字段 order by field ( value ,str1,str2,str3) 。 sql如下： 来源： https://www.cnblogs.com/shm-1255/p/8981217.html

我们的MySQL使用latin1的默认字符集，也就是说，对汉字字段直接使用GBK内码的编码进行存储，当需要对一些有汉字的字段进行拼音排序时（特别涉及到类似于名字这样的字段时），默认无法通过order by关键字正确排序。 经过网上查找，网上的办法大多是针对使用utf8字符集的数据库，主要的方法有： 1）直接转换字段为gbk，比如： SELECT * FROM table ORDER BY CONVERT( chinese_field USING gbk ) ; 或者干脆将相应字段改为gbk字符集。 来源： http://www.cnblogs.com/llinzuxin/archive/2012/04/05/2950565.html

结构和历史 1. 隔离级别有四种： READ UNCOMMITTED（未提交读），同事务中某个语句的修改，即使没有提交，对其他事务也是可见的。这个也叫脏读。 READ COMMITTED（提交读），另一个事务只能读到该事务已经提交的修改，是大多数据库默认的隔离级别。但是有下列问题，一个事务中两次读取同一个数据，由于这个数据可能被另一个事务提交了两次，所以会出现两次不同的结果，所以这个级别又叫做不可重复读。这里的不一样的数据包括虚读（两次结果不同）和幻读（出现新的或者缺少了某数据）。 REPEATABLE READ（可重复读），这个级别不允许脏读和不可重复读，比如MYSQL中通过MVCC来实现解决幻读问题。 SERIALIABLE（可串行化），这儿实现了读锁，级别最高。 2. 显示和隐式锁定：事务执行中，随时可以执行锁定，锁只有在COMMIT或ROLLBACK的时候才释放，而且所有的锁是同时释放的。这些锁定都是隐式锁定。也可以通过特定语句显式锁定，比如SELECT … LOCK IN SHARE MODE等。 3. MVCC（多版本并发控制）：通过保存数据在某个时间点的快照来实现。在INNODB中通过每行记录后保存两个隐藏的列，一个保存行的创建时间，一个保存行的过期（删除）时间，这儿的保存不是时间而是系统版本号，随着事务的数量增加而增加版本号。 SELECT

mysql联合索引 命名规则：表名_字段名 1、需要加索引的字段，要在where条件中 2、数据量少的字段不需要加索引 3、如果where条件中是 OR 关系，加索引不起作用 4、符合最 左 原则 联合索引又叫复合索引。对于复合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index (a,b,c). 可以支持 a | a,b | a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。 两个或更多个列上的索引被称作复合索引。 利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引 不同于使用两个单独的索引。复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。如果您知 道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不姓，电话簿将没有用处。 所以说创建复合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，复合索引非常有用；仅对后面的任意列执行搜索时，复合索引则没有用处。 当一个表有多条索引可走时, Mysql 根据查询语句的成本来选择走哪条索引, 联合索引的话, 它往往计算的是第一个字段(最左边那个), 这样往往会走错索引. 如: 索引Index

认真阅读了一下explain之Extra字段，前2篇关于一道sql （select * from t where a=? and b>? order by c limit 0,100 ） 如何加索引的问题答案终于浮出水面 Using index 表示使用了覆盖索引，性能上会快很多 覆盖索引 是指，索引上的信息足够满足查询请求，不需要再回到主键索引上去取数据。 Using index condition 与 Using index 的区别在于，用上了索引（利用索引完成字段的筛选过滤），但是索引列不能够包含查询要求的所有字段，需要回表补全字段 回表 是指，根据索引找到满足条件的id后，利用id回到主键索引上取出整行或者取出需要的字段 Using filesort 表示的就是需要排序，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。 "排序"这个动作，可能在内存中完成，也可能需要使用外部排序，这取决于排序所需的内存和参数 sort_buffer_size。 sort_buffer_size，就是 MySQL 为排序开辟的内存（sort_buffer）的大小。如果要排序的数据量小于 sort_buffer_size，排序就在内存中完成。但如果排序数据量太大，内存放不下，则不得不利用磁盘临时文件辅助排序。 全字段排序 可以通过 OPTIMIZER_TRACE结果