索引

列表是最常用的Python数据类型，它可以作为一个方括号内的逗号分隔值出现。 列表中的每个元素都分配一个数字 - 它的位置，或索引，第一个索引是0，第二个索引是1，依此类推。 列表可以进行的操作包括索引，切片，加，乘，检查成员。 此外，Python已经内置确定序列的长度以及确定最大和最小的元素的方法。 列表的数据项不需要具有相同的类型创建一个列表，只要把逗号分隔的不同的数据项使用方括号括起来即可。 如下所示： list1 = ['physics', 'H2O', 1997, 2000] list2 = [1, 2, 3, 4, 5 ] list3 = ["a", "b", "c", "d"] 列表的切片操作 ： l[0:2] 取列表的第一到第二个元素 l[2:5] 取列表的第三到第四个元素 l[::2] 间隔取列表元素1、3、5....l[:7:2] 取第一到第六个元素后再间隔的取取出的元素 列表的常用操作如下所示 ： li＝['day', 'eric', 'rain'] 计算列表长度并输出 print(len(li)) 3 查找元素“eric”对应索引 print(li.index("eric"))1 列表中追加元素“seven” li.append("seven") 在列表的第1个位置插入元素“Tony” li.insert(0, "tony") 修改列表第2个位置的元素为

转载 MySQL在 5.0版本中引入新特性：索引合并优化(Index merge optimization)，当查询中单张表可以使用多个索引时，同时扫描多个索引并将扫描结果进行合并。 该特新主要应用于以下三种场景： 1、 对OR语句求并集，如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果合并（union）操作，得到最终结果 2、 对AND语句求交集，如查询SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果取交集（intersect）操作，得到最终结果 3、 对AND和OR组合语句求结果 该新特性可以在一些场景中大幅度提升查询性能，但受限于MySQL糟糕的统计信息，也导致很多场景查询性能极差甚至导致数据库崩溃。 以SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx" 为例： 1、 当c1列和c2列选择性较高时，按照c1和c2条件进行查询性能较高且返回数据集较小，再对两个数据量较小的数据集求交集的操作成本也较低，最终整个语句查询高效； 2、 当c1列或c2列选择性较差且统计信息不准时

看了很多讲B树和B+树的文章，大多都是围绕各自的特性讲的，第一，树中每个结点最多含有m个孩子（m>=2）；第二，……我也是从这些文章里弄懂了各种树的联系与区别，要真写，我可能还不如人家写得好。所以就在这里简明扼要的用几张图记录一下主要区别吧。 为了便于说明，我们先定义一条数据记录为一个二元组[key,data]，key为记录的键值，key唯一；data为数据记录除key外的数据。 B树 每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。 B+树 只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。 后来，在B+树上增加了顺序访问指针，也就是每个叶子节点增加一个指向相邻叶子节点的指针，这样一棵树成了数据库系统实现索引的首选数据结构。 原因有很多，最主要的是这棵树矮胖，呵呵。一般来说，索引很大，往往以索引文件的形式存储的磁盘上，索引查找时产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小，I/O次数越少。 那为什么是B+树而不是B树呢，因为它内节点不存储data，这样一个节点就可以存储更多的key。 在MySQL中，最常用的两个存储引擎是MyISAM和InnoDB，它们对索引的实现方式是不同的。 MyISAM

背景介绍 最近在写SQL语句时，对选择IN 还是Exists 犹豫不决，于是把两种方法的SQL都写出来对比一下执行效率，发现IN的查询效率比Exists高了很多，于是想当然的认为IN的效率比Exists好，但本着寻根究底的原则，我想知道这个结论是否适用所有场景，以及为什么会出现这个结果。 网上查了一下相关资料，大体可以归纳为：外部表小，内部表大时，适用Exists；外部表大，内部表小时，适用IN。那我就困惑了，因为我的SQL语句里面，外表只有1W级别的数据，内表有30W级别的数据，按网上的说法应该是Exists的效率会比IN高的，但我的结果刚好相反！！ “没有调查就没有发言权”！于是我开始研究IN 和Exists的实际执行过程，从实践的角度出发，在根本上去寻找原因，于是有了这篇博文分享。 实验数据 我的实验数据包括两张表：t_author表 和 t_poetry表。 对应表的数据量： t_author表，13355条记录； t_poetry表，289917条记录。 对应的表结构如下： CREATE TABLE t_poetry ( id bigint(20) NOT NULL AUTO_INCREMENT, poetry_id bigint(20) NOT NULL COMMENT '诗词id', poetry_name varchar(200) NOT NULL COMMENT

找到mysql的安装目录的bin/myisamchk工具，在命令行中输入： myisamchk -c -r ../data/tablename/posts.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql，问题就解决了。 问题分析： 1、 错误产生原因，有网友说是频繁查询和更新dede_archives表造成的索引错误，因为我的页面没有静态生成，而是动态页面，因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏，如：数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 问题的编号为145 2、问题解决办法。 当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示： % myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName 第一种是最快的，用来修复最普通的问题

-------sql数据库优化------ -------索引----- 1.索引的目的：提高查询效率 2.索引分两种 2.1聚集索引（物理），一个表中只能有一个聚集索引 2.2非聚集索引（逻辑），一个表中可以有多个非聚集索引 3.增加索引后，会增加额外的储存空间，同时降低了增加新记录，修改，删除效率 4.只在经常查询的列上建索引，不要建太多索引 ----------语法----------- –增加聚集索引 create clustered index 索引名 on 表名(列名) –删除索引 drop index 表名.索引名 –增加非聚集索引 create nonclustered index 索引名 on 表名(列名) 来源： CSDN 作者： BowenXu11 链接： https://blog.csdn.net/BowenXu11/article/details/104720056

1、建表语句： create table 表名（字段名 类型，字段名 类型）； --删除表： drop table 表名； --修改表： alter table 表名 add 字段名 类型； --修改字段： alter table 表名 modify（字段名 类型）； --重命名字段： alter table 表名 rename column 字段名 to 新字段名； --重命名表 ： rename 表名 to 新表名； --删除字段： alter table 表名 drop column 字段名； 2、序列（sequence） --创建sequence create sequence 序列名 [INCREMENT BY n] [START WITH n] [{MAXVALUE/ MINVALUE n| NOMAXVALUE}] [{CYCLE|NOCYCLE}] [{CACHE n| NOCACHE}]; 其中： 1) INCREMENT BY用于定义序列的步长，如果省略，则默认为1，如果出现负值，则代表Oracle序列的值是按照此步长递减的。 2) START WITH 定义序列的初始值(即产生的第一个值)，默认为1。 3) MAXVALUE 定义序列生成器能产生的最大值。选项NOMAXVALUE是默认选项，代表没有最大值定义，这时对于递增Oracle序列

什么是索引？索引就是排好序的数据结构，可以帮助我们快速的查找到数据 推荐一个网站，可以演示各种数据结构：https://www.cs.usfca.edu/~galles/visualization/Algorithms.html --------------------------------------------------------------- 图解几种数据结构： 二叉树：如果数据是单边增长的情况 那么出现的就是和链表一样的数据结构了，树高度大 红黑树：在二叉树的基础上多了树平衡，也叫二叉平衡树，不像二叉树那样极端的情况会往一个方向发展。 同样我们查找6，在二叉树中我们需要经过6个节点才能找到（1-2-3-4-5-6）,红黑树中我们只需要3个节点（2-4-6），但是mysql索引的数据结构并不是红黑树，因为如果数据量大了之后，树的高度就会很大。 B树：在红黑树的基础上，每个节点可以存放多个数据 这个时候我们查找6 只需要2个节点就可以了，而且树的高度也比红黑树矮。 B+树：B树的变种 你会发现非叶子节点是会重复的，就像上面4，在叶子节点上面也出现了4，这是为什么呢？因为它需要在叶子上面存放数据。那又是怎么存放数据的呢？ --------------------------------------------------------------- mysql索引为什么用B

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秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

MongoDB常用命令： 超级用户相关： use admin #增加或修改用户密码 db.addUser(ixigua,'pwd') #查看用户列表 db.system.users.find() #用户认证 db.auth(ixigua,'pwd') #删除用户 db.removeUser('mongodb') #查看所有用户 show users #查看所有数据库 show dbs #查看所有的collection show collections #查看各collection的状态 db.printCollectionStats() #查看主从复制状态 db.printReplicationInfo() #修复数据库 db.repairDatabase() #设置记录profiling，0=off 1=slow 2=all db.setProfilingLevel(1) #查看profiling show profile #拷贝数据库 db.copyDatabase('mail_addr','mail_addr_tmp') #删除collection db.mail_addr.drop() #删除当前的数据库 db.dropDatabase() 客户端连接： /usr/local/mongodb/bin/mongo 8.8.88/ixigualib -u ixigua -p