我同意Unreason的分支.但是有一些事情需要了解这个案例.
 
这称为歪斜和歪斜杀戮.这是部分索引的完美用途,您可以排除95％的付费发票,并仅索引更有趣和有选择性的统计数据.但你没有那个.您可以将所有行水平分区为单独的表/分区,但是您需要考虑行迁移(从一个状态移动到另一个状态),这很昂贵. DBMS必须执行更新,删除和插入以更改状态.如果你是一个会伤害的高容量系统.
 
忘记你所说的是否基于选择性进行索引,因为在快速变化的列上放置索引通常也是一个坏主意.您的索引将具有热块,其中所有步骤1被移除,而另一个步骤2的所有步骤被插入,而且,顺便说一下,某些步骤2将被同时移除到步骤3中.这不会很好地扩展.
 
我建议将您的状态垂直分区到一个单独的表中.
 
您的发票表将包含PK以及除状态之外的所有列.
 
您的状态可以通过两种方式处理.该表将PK值作为FK返回到发票表,状态和您输入该状态时的时间戳.最好的是状态上的水平分区表.您将为每种状态分配一个分区.因此,找到所有或一个“已放置”状态将分区修剪并只读取它所需的分区 – 这是一个非常少的块.由于行太窄,因此您可能会在一个块上获得400个发票状态.查看任何一张发票的状态很容易,因为PK上有一个全局索引.
 
如果您的RDBMS不支持使用行迁移进行分区,则需要将这些分区作为表进行管理,然后从一个分区中删除并插入另一个分区.您将这些移动封装在过程中的事务中,因此您可以保持数据清洁.每张发票都在一个且只有一个状态表中.更难的部分是按发票ID查询,您必须检查每张表以查看它的位置.
 
你有另一种选择
 
您可以编写付费状态.如果它是分区表,您只需在发票状态表中移动到付款时删除该发票. (当然,您可以将付费记录写入奖励材料中提到的历史记录表).然后你将对状态表进行外连接,并且null表示已付费.如果您几乎从不查询付费状态,那么实际上没有理由进行快速查询.
 
奖金材料
 
在任何一种情况下,您都希望在报告表中跟踪这些移动.每次更新状态时,您都希望将其写入历史记录表.最后,您需要分析我称之为运输时间的内容.按月填写到付费的平均时间是多少？由于经济不景气,这种情况会增加吗？从月份到装满的运输时间是多少.由于度假时身体缺失,夏季月份需要更长时间吗？你明白了.通过更新该列,您将丢失这些答案,因此您需要将该历史记录日志嵌入到您的过程中.

 
我有csv文件中的数据。其中一列列出一个人的姓名,该列后面的所有行都提供有关该人的一些描述性属性,直到下一个人的姓名出现为止。我可以通过ltype列判断行何时有名称或属性,该列中的n表示该行中的name值实际上是一个名称,该列中的a表示name列中的数据是一个属性。属性是编码的,我有60万行数据。这是一个样品。将对数据进行分组,并通过将RID重置为1来指示每个分组的开始时间。
 
{'LTYPE': 'N', 'RID': '1', 'NAME': 'Jason Smith'}
 
{'LTYPE': 'A', 'RID': '2', 'NAME': 'DA'}
 
{'LTYPE': 'A', 'RID': '3', 'NAME': 'B'}
 
{'LTYPE': 'N', 'RID': '4', 'NAME': 'John Smith'}
 
{'LTYPE': 'A', 'RID': '5', 'NAME': 'BC'}
 
{'LTYPE': 'A', 'RID': '6', 'NAME': 'CB'}
 
{'LTYPE': 'A', 'RID': '7', 'NAME': 'DB'}
 
{'LTYPE': 'A', 'RID': '8', 'NAME': 'DA'}
 
{'LTYPE': 'N', 'RID': '9', 'NAME': 'Robert Smith'}
 
{'LTYPE': 'A', 'RID': '10', 'NAME': 'BC'}
 
{'LTYPE': 'A', 'RID': '11', 'NAME': 'DB'}
 
{'LTYPE': 'A', 'RID': '12', 'NAME': 'CB'}
 
{'LTYPE': 'A', 'RID': '13', 'NAME': 'RB'}
 
{'LTYPE': 'A', 'RID': '14', 'NAME': 'VC'}
 
{'LTYPE': 'N', 'RID': '15', 'NAME': 'Harvey Smith'}
 
{'LTYPE': 'A', 'RID': '16', 'NAME': 'SA'}
 
{'LTYPE': 'A', 'RID': '17', 'NAME': 'AS'}
 
{'LTYPE': 'N', 'RID': '18', 'NAME': 'Lukas Smith'}
 
{'LTYPE': 'A', 'RID': '19', 'NAME': 'BC'}
 
{'LTYPE': 'A', 'RID': '20', 'NAME': 'AS'}
 
我要创建以下内容:
 
{'PERSON_ATTRIBUTES': 'DA B ', 'LTYPE': 'N', 'RID': '1', 'PERSON_NAME': 'Jason Smith', 'NAME': 'Jason Smith'}
 
{'PERSON_ATTRIBUTES': 'DA B ', 'LTYPE': 'A', 'RID': '2', 'PERSON_NAME': 'Jason Smith', 'NAME': 'DA'}
 
{'PERSON_ATTRIBUTES': 'DA B ', 'LTYPE': 'A', 'RID': '3', 'PERSON_NAME': 'Jason Smith', 'NAME': 'B'}
 
{'PERSON_ATTRIBUTES': 'BC CB DB DA ', 'LTYPE': 'N', 'RID': '4', 'PERSON_NAME': 'John Smith', 'NAME': 'John Smith'}
 
{'PERSON_ATTRIBUTES': 'BC CB DB DA ', 'LTYPE': 'A', 'RID': '5', 'PERSON_NAME': 'John Smith', 'NAME': 'BC'}
 
{'PERSON_ATTRIBUTES': 'BC CB DB DA ', 'LTYPE': 'A', 'RID': '6', 'PERSON_NAME': 'John Smith', 'NAME': 'CB'}
 
{'PERSON_ATTRIBUTES': 'BC CB DB DA ', 'LTYPE': 'A', 'RID': '7', 'PERSON_NAME': 'John Smith', 'NAME': 'DB'}
 
{'PERSON_ATTRIBUTES': 'BC CB DB DA ', 'LTYPE': 'A', 'RID': '8', 'PERSON_NAME': 'John Smith', 'NAME': 'DA'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'N', 'RID': '9', 'PERSON_NAME': 'Robert Smith', 'NAME': 'Robert Smith'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'A', 'RID': '10', 'PERSON_NAME': 'Robert Smith', 'NAME': 'BC'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'A', 'RID': '11', 'PERSON_NAME': 'Robert Smith', 'NAME': 'DB'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'A', 'RID': '12', 'PERSON_NAME': 'Robert Smith', 'NAME': 'CB'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'A', 'RID': '13', 'PERSON_NAME': 'Robert Smith', 'NAME': 'RB'}
 
{'PERSON_ATTRIBUTES': 'BC DB CB RB VC ', 'LTYPE': 'A', 'RID': '14', 'PERSON_NAME': 'Robert Smith', 'NAME': 'VC'}
 
{'PERSON_ATTRIBUTES': 'SA AS ', 'LTYPE': 'N', 'RID': '15', 'PERSON_NAME': 'Harvey Smith', 'NAME': 'Harvey Smith'}
 
{'PERSON_ATTRIBUTES': 'SA AS ', 'LTYPE': 'A', 'RID': '16', 'PERSON_NAME': 'Harvey Smith', 'NAME': 'SA'}
 
{'PERSON_ATTRIBUTES': 'SA AS ', 'LTYPE': 'A', 'RID': '17', 'PERSON_NAME': 'Harvey Smith', 'NAME': 'AS'}
 
{'PERSON_ATTRIBUTES': 'BC AS ', 'LTYPE': 'N', 'RID': '18', 'PERSON_NAME': 'Lukas Smith', 'NAME': 'Lukas Smith'}
 
{'PERSON_ATTRIBUTES': 'BC AS ', 'LTYPE': 'A', 'RID': '19', 'PERSON_NAME': 'Lukas Smith', 'NAME': 'BC'}
 
{'PERSON_ATTRIBUTES': 'BC AS ', 'LTYPE': 'A', 'RID': '20', 'PERSON_NAME': 'Lukas Smith', 'NAME': 'AS'}
 
我首先得到ltype的索引位置
 
nameIndex=[]
 
attributeIndex=[]
 
for line in thedata:
 
if line['LTYPE']=='N':
 
nameIndex.append(int(line["RID"])-1)
 
if line['LTYPE']=='A':
 
attributeIndex.append(int(line["RID"])-1)
 
因此,我在一个列表中将每一行的列表索引归类为名称,在另一个列表中将每一行的列表索引归类为属性。然后可以很容易地将名称附加到每个观察上,如下所示
 
for counter, row in enumerate(thedata):
 
if counter in nameIndex:
 
row['PERSON_NAME']=row['NAME']
 
person_NAME=row['NAME']
 
if counter not in nameIndex:
 
row['PERSON_NAME']=person_NAME
 
我正在努力确定和分配每个人的属性列表。
 
首先,我需要将属于自己的属性组合在一起,所以我做到了:
 
newAttribute=[]
 
for counter, row in enumerate(thedata):
 
if counter in attributeIndex:
 
tempAttribute=tempAttribute+' '+row['NAME']
 
if counter not in attributeIndex:
 
if counter==0:
 
tempAttribute=""
 
pass
 
if counter!=0:
 
newAttribute.append(tempAttribute.lstrip())
 
tempAttribute=""
 
我的方法的一个问题是,由于循环在添加前完成,我仍然必须将最后一个组添加到newattribute列表中。所以为了得到分组属性的列表,我必须运行
 
newAttribute.append(tempAttribute)
 
但即便如此,我似乎也找不到一个干净的方法来添加我必须分两步完成的属性。首先,我创建一个字典,名称索引位置作为键,属性作为值
 
tempDict={}
 
for each in range(len(nameIndex)):
 
tempdict[nameIndex[each]]=newAttribute[each]
 
我在列表中循环一次,将属性放在名称行上
 
for counter,row in enumerate(thedata):
 
if counter in tempDict:
 
thedata[counter]['TA']=tempDict[counter]
 
然后我再次检查密钥“ta”是否存在,并使用该存在设置person_属性密钥
 
for each in thedata:
 
if each.has_key('TA'):
 
each['PERSON_ATTRIBUTES']=each['TA']
 
holdAttribute=each['TA']
 
else:
 
each['PERSON_ATTRIBUTES']=holdAttribute
 
必须有一个更干净的方法来考虑这个问题,所以我想知道是否有人愿意给我指出一些我可以阅读的函数的方向,这样我就可以清理代码了。我知道我还得把“助教”钥匙放下,但我想我已经占了足够的空间。

 
这周工作时曾遇到一个问题。在一个MYSQL的表里做类似下面这一个很简单查询的时候耗时接近1秒钟的时间。
 
select sum(col5) , sum(col6) from table_name
 
where col_key_2='value1' and col_key_3 = 'value2'
 
表定义如下：
 
CREATE TABLE `table_name` (
 
`col_key_1` date NOT NULL default '0000-00-00',
 
`col_key_3` varchar(32) NOT NULL default '',
 
`col_key_2` varchar(32) NOT NULL default '',
 
`col5` bigint(20) unsigned default NULL,
 
`col6` bigint(20) unsigned default NULL,
 
`col7` bigint(20) unsigned default NULL,
 
`col8` bigint(20) unsigned default NULL,
 
`col_key_4` varchar(32) NOT NULL default '',
 
PRIMARY KEY (`col_key_1`,`col_key_2`,`col_key_3`,`col_key_4`)
 
) ENGINE=MyISAM DEFAULT CHARSET=latin1 | 整个表里大概只有200多万条数据。但查询的速度居然会慢到1秒钟才能查询出来，完全不可以忍受。
 
然后我给这张加上了另一个索引：KEY `class` (`col_key_2`,`col_key_3`)
 
查询的速度立马提高到0.00秒。
 
于是认真的查看了一下mysql 手册的8.3小节。
 
MySQL索引的种类和作用
 
mysql的索引分成：primary key, unique, index, fulltext index。 primary key是主键， unique是唯一索引， index是普通的索引。fulltext index是全文索引。 索引的作用就像C语言里的指针那样，直接指向表的一行。
 
可以对用col_name(N) 对符串的前N个字节做索引。 text类型和blob类型则必须要对前N个字节做索引。MYISAM最多支持1000个字节的索引， INNODB最多支持767字节的索引。
 
索引有下列作用：
 
1 帮助where语句快速查询。
 
2 进行多表连接
 
3 找到最大值和最小值(应该只有B-tree索引有这个功能，hash索引没有这个功能)
 
4 sort(应该只有B-tree索引有这个功能，hash索引没有这个功能)和group
 
多列索引
 
多列索引在对多个列同时进行查询的时候特别有用。多列索引最多支持16列。可以这样理解多列索引：
 
把多个列concat在一起，然后再对这个concat的值做一个索引。
 
比较神奇的一点是，比如你有一个索引针对col1 col2 col3这3个列时， 只查询col1和只查询col1 col2时也能用到这个索引。
 
比如有这个表：
 
CREATE TABLE test (
 
id INT NOT NULL,
 
last_name CHAR(30) NOT NULL,
 
first_name CHAR(30) NOT NULL,
 
PRIMARY KEY (id),
 
INDEX name (last_name,first_name)
 
); 下面这些查询都可以用到多列索引：
 
SELECT * FROM test WHERE last_name='Widenius';
 
SELECT * FROM test
 
WHERE last_name='Widenius' AND first_name='Michael';
 
SELECT * FROM test
 
WHERE last_name='Widenius'
 
AND (first_name='Michael' OR first_name='Monty');
 
SELECT * FROM test
 
WHERE last_name='Widenius'
 
AND first_name >='M' AND first_name < 'N'; 下面这些查询不能用到多列索引：
 
SELECT * FROM test WHERE first_name='Michael';
 
SELECT * FROM test
 
WHERE last_name='Widenius' OR first_name='Michael';
 
你可以在sql语句前使用explain语句来确定是否用到了索引。
 
比如下面这个查询就可以用到class这个索引
 
mysql> explain select sum(col5) , sum(col6) from table_name
 
where col_key_2='value1' and col_key_3 = 'value2' \G
 
*************************** 1. row ***************************
 
id: 1
 
select_type: SIMPLE
 
table: table_name
 
type: ref
 
possible_keys: class
 
key: class
 
key_len: 68
 
ref: const,const
 
rows: 1
 
Extra: Using where
 
1 row in set (0.00 sec) 而下面这个查询则不能使用到索引：
 
mysql> explain select sum(col5) , sum(col6) from table_name
 
where col5='value1' and col_key_3 = 'value2' \G
 
*************************** 1. row ***************************
 
id: 1
 
select_type: SIMPLE
 
table: table_name
 
type: ALL
 
possible_keys: NULL
 
key: NULL
 
key_len: NULL
 
ref: NULL
 
rows: 2357455
 
Extra: Using where
 
1 row in set (0.00 sec)
 
索引的好坏
 
MySQL使用一个指标value group size来衡量索引的好坏。什么是value group呢？ 就是具有相同索引key值的行数。这个指标显然是越小越好。最理想的情况就是每一个key值只对应1行， 这样的话我们的每次搜索一个key值都只返回一行，显然速度非常快。
 
可以用mysql提供的工具查看一个表的索引的好坏。可以先用analyze table语句更新统计，然后用show index来查看统计：
 
mysql> analyze table table_name;
 
+-----------------+---------+----------+----------+
 
| Table | Op | Msg_type | Msg_text |
 
+-----------------+---------+----------+----------+
 
| stat.table_name | analyze | status | OK |
 
+-----------------+---------+----------+----------+
 
1 row in set (3.13 sec)
 
mysql> show index in table_name;
 

 
table_name这张表有两个索引PRIMARY和class，PRIMARY这个索引是一个包含4列的多列索引。
 
Cardinality这个值表示索引值的不同的行数。
 
例如：
 
col_key_1值有18行。
 
col_key_1＋col_key_2 值有392909行。
 
col_key_1 + col_key_2 + col_key_3 值有235745行。
 
col_key_1 + col_key_2 + col_key_3 + col_key_4值有235745行。
 
通过索引值的行数，我们就可以看出来索引好还是不好了。索引值不同的行数越多索引就越好。当索引值不同的行数=表的总行数就达到最理想的情况 value group size = 1了。
 
B-tree索引和Hash索引的比较
 
默认情况下MySQL都是使用B-tree索引。来谈一下Hash索引的缺陷:
 
1 只能处理’=‘ 这种where 子句，而对于< >是无能为力的。 这和B-tree索引是有序的，Hash无序的有关。
 
2 无法处理order by。 原因同上。
 
3 无法得知两行之间的距离。 原因同上。
 
4 只能搜完整的字段，不能只搜字段的一部分。 而对于B-tree索引， 支持搜索字符串最左边的一部分。例如"police%" 。

 
是什么
 
索引用于快速的查询某些特殊列的某些行。如果没有索引， MySQL 必须从第一行开始，然后通过搜索整个表来查询有关的行。表越大，查询的成本越大。如果表有了索引的话，那么 MySQL 可以很快的确定数据的位置，而不用查询整个表格。这比顺序的读取每一行要快的多。索引就像我们查字典时的目录一样，我们通过查询字典的目录，可以定位到某一行数据。
 
大多数的 MySQL 的索引(主键索引，唯一索引，普通索引，全文索引)都是 B-trees  结构。例外的情况有：在空间数据类型使用 R-trees 结构。存储引擎为 MEMORY 的数据库，也可以支持哈希索引。InnoDB 存储引擎的全文索引使用反向列表结构。
 
使用场景
 
MySQL 会使用到索引的场景如下：
 
1.根据一个条件快速的匹配到对应的行。
 
2.缩小查询影响行数。如果一个查询字段有多个索引，MySQL 通常选择使用影响行数最小的索引(选择性最高的索引)。索引的选择性的计算 select count(distinct name) / count(*) from table;
 
3.对于组合索引，索引左边的列可以用索引前缀优化器来查询数据。例如，你有个三列的组合索引(col1,col2,col3) ，那么你可以使用索引查询(col1),(col1,col2),(col1,col2,col3)这三种组合的数据。有关于组合索引，详细请看另外一篇博客 MySQL 组合索引
 
4.当和其他表进行连表查询的时候，如果进行判断的列的数据类型和大小相同，那么再这两个列上使用索引，可以让判断更加效率。例如：在如下查询中，给tb1.name和tb2.name添加索引会提升查询效率。SELECT * FROM tb1, tb2 WHERE tb1. name = tb2. name
 
在这里，VARCHAR 与 CHAR 被认为是相同的类型。需要注意的是，如果要让索引生效，不仅需要类型一致，大小也必须一致。例如，VARCHAR(10) 和 CHAR(10) 大小相同可以使用索引，但 VARCHAR(10) 与 CHAR(15)就无法使用索引。
 
5.查找索引列的 MIN() 或 MAX()值。
 
6.通过索引列进行排序或分组，或者组合索引的左前缀进行排序或分组。
 
7.查询索引列的内容。(如果只需要返回索引列的值，那么不需要查询数据行，直接从内存中读取检索值。这种情况称为覆盖索引)例如： SELECT key_part FROM table WHERE key_part=1
 
对于小型表或报表查询处理大多数或所有行的大型表的查询，索引不太重要。当查询需要访问大多数行时，顺序读取比通过索引更快。顺序读取可以最大限度地减少磁盘搜索，即使查询不需要所有行也是如此。只有数据较大，并且需要访问其中一部分数据的时候，索引才会显得比较重要。
 
怎么用
 
查看索引
 
SHOW INDEX FROM table
 
运行后，显示结果如下：
 

 
其中，各个字段的含义：
 
table： 表的名称
 
Non_unique： 索引是否可以重复。不可以重复则为0；可以重复则为1。
 
Key_name： 索引名称。创建的时候，可以选择输入，不输入 MySQL 自动生成。如果索引是主键，则名称始终为 PRIMARY。
 
Seq_in_index： 索引中的列序列号，从1开始。
 
Column_name： 索引涉及到的列的名称。
 
Collation：列如何在索引中排序。这可以具有值 A(ascending 升序)，D ( descending 降序)或NULL(未排序)。
 
Cardinality： 索引中唯一值的数量(不是实时更新的准确数据)。
 
Sub_part： 索引前缀长度。如果使用字段的部分字符作为索引，那么显示索引字符数量。如果使用整个字段都被索引，那么为 NULL。
 
Packed： key的打包方式，NULL 表示不打包。
 
Null： 索引列包含 NULL 或者 ‘’ 的时候，会是 YES。
 
Index_type： 索引类型。(BTREE， FULLTEXT，HASH， RTREE)之一。
 
Comment： 未在当前列中描述的索引信息，例如 disabled 索引是否已禁用。
 
Index_comment： 在创建索引时提供的注释。
 
Visible： 索引是否对优化程序可见(有的版本会出现该信息)。
 
添加索引
 
CREATE INDEX index_name ON table_name (key_part,...)
 
ALTER TABLE t1 ADD INDEX index_name (key_part)
 
通常，在创建表时创建索引。对于InnoDB存储引擎的表。其中主键确定数据的物理布局，可以向现有表中添加索引。key_part 表示组成索引的列的列名，如果是多个列名，那么将产生一个组合索引。在 key_part 参数后可以添加 ASC 或者 DESC 去指定索引按照正序排列还是倒序排列。
 
关于创建索引需要注意的是：
 
组合索引
 
组合索引是一个由多个列组成的索引。举例说明：例如在表 address 中有三个字段，分别为 Provincial 省 city 市 county 县 在建表的时候，用这三个字段组成一个组合索引。代码如下：
 

 

 
1 CREATE TABLEaddress (2 provincial VARCHAR (10),3 city VARCHAR (10),4 county VARCHAR (10),5 INDEX(provincial, city, county)6 )
 
CREATE TABLE address
 
这里的索引是这样创建的：首先按照省排序，然后，再根据同一个省的内容，按照市进行排序，最后，按照县去排序。即，首先按照第一列进行索引排序，如果第一列内容一致，那么按照第二列进行排序，以此类推。
 
前缀索引
 
如果将字符串的列作为索引，可以创建前缀索引。一般情况下某个前缀的选择性也是足够高的，足以满足查询性能。对于BLOB，TEXT，或者很长的VARCHAR类型的列，必须使用前缀索引。前缀索引以字节为单位。前缀索引支持的长度取决于存储引擎。例如，对于InnoDB 使用 REDUNDANT 或 COMPACT 行格式的表， 前缀最长可达767字节。对于InnoDB使用DYNAMIC 或 COMPRESSED 行格式的表， 前缀长度限制为3072字节 。对于MyISAM表，前缀长度限制为1000个字节。
 
如果指定的索引前缀超过最大列数据类型大小，对于非唯一索引，如果启用了严格的SQL模式，创建会发生错误。如果未启用严格SQL模式，索引长度减少到最大列数据类型大小，并产生警告。
 
创建前缀索引的长度，取决于索引的选择性。详见另外一篇博客：索引选择性
 
创建前缀索引语法如下(这里的10 表示截取前10个字符)：
 
CREATE INDEX key_part_name ON table_name (key_part(10));
 
ALTER TABLE table_name ADD INDEX index_name (key_part(10))
 
前缀索引可以兼顾索引大小和查询速度。可以利用相对更小的空间，用更快的速度，查出数据。但是它也有缺点：前缀索引无法用于 ORDER BY 和 GROUP BY 操作，也不能用于索引覆盖。
 
方法索引
 
这里的索引类型英文名称为：Functional Key Parts 这里作者并不清楚官方的翻译名称为啥，只是根据索引的方式进行翻译。如果不对，欢迎大神指正。
 
这个索引类似于两个前缀索引的拼接。直接举个例子就明白了：在 t1 表中有两个列，col1 和 col2 我要创建一个包含完整的 col1 列和 col2 列的前10个字节组成一个组合索引。代码如下：
 

 

 
CREATE TABLEt1 (
 
col1VARCHAR(10),
 
col2VARCHAR(20),INDEX (col1, col2(10))
 
);
 
Functional Key Parts
 
在 MySQL 8.0.13版本及更高版本中，MySQL 支持表达式进行索引。这里，需要将运算表达式写在括号内进行缩印的声明。例如：
 

 

 
1 --方法索引
 
2 CREATE TABLEt1 (3 col1 INT,4 col2 INT,5 INDEX func_index ((ABS(col1)))6 );7
 
8 CREATE INDEX idx1 ON t1 ((col1 +col2));9
 
10 CREATE INDEX idx2 ONt1 (11 (col1 +col2),12 (col1 -col2),13 col114 );15
 
16 ALTER TABLE t1 ADD INDEX ((col1 * 40) DESC);
 
Functional Key Parts
 
唯一索引
 
通过 UNIQUE 创建的索引。索引列的内容非null值的时候必须是唯一的，null值可以不唯一。如果添加重复值，则会发生错误。如果在创建唯一索引的时候指定前缀值，那么前缀必须是唯一的。创建语法： CREATE UNIQUE INDEX unique_index_name ON table_name (key_part)
 
全文索引
 
全文索引，顾名思义，支持全文检索的索引。仅支持 Innodb 和 MyISAM 两种存储引擎。并且只能包括 CHAR, VARCHAR 和 TEXT 列，索引始终发生在整个列上，不支持前缀索引。(即使写了也没用)可以对字段进行全文检索。对于数据量比较大的数据集，先将数据加载到没有数据的表中，然后再添加索引，效率要比把数据直接向有索引的表中添加高。
 
空间索引
 
空间索引是为空间搜索提供一种合适的数据结构，以提高搜索速度。对于空间索引，作者研究并不多，这里大概介绍下空间索引的用处。等以后研究深刻后，再补上这部分内容。首先，空间索引是干什么用的？举例：当我们需要按照某个点，查询附近的50米内都有哪些客户存在。对于这个需求，可能的解法如下：
 
1.我们可以根据用户的经纬度，去计算每个人跟我们的当前点的距离，然后跟50米去作对比。这在客户数据量少的时候，还可以这么做，数据量大的时候，将会特别的浪费性能。
 
2.先画一个方框，把50米范围的数据的经纬度画出来，通过经纬度的值进行筛选后，得到一个正方形的区域，然后再进行计算。这时候，会少很多计算，但依然不是最优方案。
 
3.使用空间索引。将空间按照一定规则划分为不同的区域，在检索的时候，根据设计的区域，取出相应的数据。空间索引结构图如下(图片来自知乎)：
 

 
删除索引
 
删除索引没啥好说的，语句如下：
 

 

 
1 DROP INDEX index_name ONtalbe_name2 ALTER TABLE table_name DROP INDEX index_name
 
DROP INDEX
 
如果索引所在的列删除，那么该列对应的索引也会自动删除。
 
索引优化
 
主键优化
 
表的主键是唯一且非空的索引，在使用InnoDB存储引擎的时候，表数据直接挂载在主键的叶子节点上，是查询速度最快的索引。
 
如果表的内容很多，并且很重要。但是没有明显的列和列的集合作为主键的话，可以单独创建一个自动增长的值作为主键。当使用外链查询的时候，这个id可以作为指向内容的指针。
 
外键优化
 
如果你的表有很多列，你可以将查询频率比较低的列拆分到其他表格，并通过复制id的方式让它们与主表关联。这样，每个小表都会有个主键来快速查找其他数据。在查询的时候，就可以仅查询自己需要的列集。这时，查询会执行较少的 I/O 并且占用较少的内存。整体原则是：为了提高性能，尽可能少的从磁盘读取数据。这就是拆表的原则。