在mysql当中创建索引有什么限制

MySQL索引类型包括：

一、普通索引

这是最基本的索引，它没有任何限制。有以下几种创建方式：

1.创建索引

代码如下:

CREATE INDEX indexName ON mytable(username(length))

如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。

2.修改表结构

代码如下:

ALTER mytable ADD INDEX [indexName] ON (username(length)) -- 创建表的时候直接指定。

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) )

-- 删除索引的语法：

DROP INDEX [indexName] ON mytable

二、唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：

代码如下:

CREATE UNIQUE INDEX indexName ON mytable(username(length))

-- 修改表结构

ALTER mytable ADD UNIQUE [indexName] ON (username(length))

-- 创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) )

三、主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

代码如下:

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) )

当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

四、组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

代码如下:

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL )

为了进一步榨取MySQL的效率，就要考虑建立组合索引。

二：使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

1.索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

2.使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O *** 作。

3.索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序 *** 作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

4.like语句 *** 作

一般情况下不鼓励使用like *** 作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

5.不要在列上进行运算

select * from users where YEAR(adddate)<2007

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成:

select * from users where adddate<‘2007-01-01'

6.不使用NOT IN和<> *** 作。

三：sql优化原则

常见的简化规则如下：

1.不要有超过5个以上的表连接（JOIN）

2.考虑使用临时表或表变量存放中间结果。

3.少用子查询

4.视图嵌套不要过深,一般视图嵌套不要超过2个为宜。

5.连接的表越多，其编译的时间和连接的开销也越大，性能越不好控制。

6.最好是把连接拆开成较小的几个部分逐个顺序执行。

7.优先执行那些能够大量减少结果的连接。

8.拆分的好处不仅仅是减少SQL Server优化的时间，更使得SQL语句能够以你可以预测的方式和顺序执行。

如果一定需要连接很多表才能得到数据，那么很可能意味着设计上的缺陷。

如何合理创建Oracle数据库索引的3个要求：

在Oracle数据库中，创建索引虽然比较简单。但是要合理的创建索引则比较困难了。笔者认为，在创建索引时要做到三个适当，即在适当的表上、适当的列上创建适当数量的索引。虽然这可以通过一句话来概括优化的索引的基本准则，但是要做到这一点的话，需要数据库管理员做出很大的努力。具体的来说，要做到这个三个适当有如下几个要求。

一、 根据表的大小来创建索引。

虽然给表创建索引，可以提高查询的效率。但是数据库管理员需要注意的是，索引也需要一定的开销的。为此并不是说给所有的表都创建索引，那么就可以提高数据库的性能。这个认识是错误的。恰恰相反，如果不管三七二十一，给所有的表都创建了索引，那么其反而会给数据库的性能造成负面的影响。因为此时滥用索引的开销可能已经远远大于由此带来的性能方面的收益。所以笔者认为，数据库管理员首先需要做到，为合适的表来建立索引，而不是为所有的表建立索引。

一般来说，不需要为比较小的表创建索引。如在一个ERP系统的数据库中，department表用来存储企业部门的信息。一般企业的部分也就十几个，最多不会超过一百个。这100条记录对于人来说，可能算是比较多了。但是对于计算机来说，这给他塞塞牙缝都还不够。所以，对类似的小表没有必要建立索引。因为即使建立了索引，其性能也不会得到很大的改善。相反索引建立的开销，如维护成本等等，要比这个要大。也就是说，付出的要比得到的多，显然违反常理。

另外，就是对于超大的表，也不一定要建立索引。有些表虽然比较大，记录数量非常的多。但是此时为这个表建立索引并一定的合适。如系统中有一张表，其主要用来保存数据库中的一些变更信息。往往这些信息只给数据库管理员使用。此时为这张表建立索引的话，反而不合适。因为这张表很少用到，只有在出问题的时候才需要查看。其次其即使查看，需要查询的纪录也不会很多，可能就是最近一周的更新记录等等。对于对于一些超大的表，建立索引有时候往往不能够达到预计的效果。而且在打表上建立索引，其索引的开销要比普通的表大的多。那么到底是否给大表建立索引呢?笔者认为，主要是看两个方面的内容。首先是需要关注一下，在这张大表中经常需要查询的记录数量。一般来说，如果经常需要查询的数据不超过10%到15%的话，那就没有必要为其建立索引的必要。因为此时建立索引的开销可能要比性能的改善大的多。这个比例只是一个经验的数据。如果数据库管理员需要得出一个比较精确的结论，那么就需要进行测试分析。即数据库管理员需要测试一下全表扫描的时间，看看其是否比建立索引后的查询时间要长或者短。如果是长的话，则说明有建立索引的必要。但是如果没有的话，则说明还是全表扫描速度来的快。此时也就没有必要建立索引了。

总之，在考虑是否该为表建立索引时，一般来说小表没有建立索引的必要。而对于打表的话，则需要进行实际情况实际分析。简单一点的，可以根据大致的比率来确定。如果要精确一点的，则可以进行全表扫描性能分析，以判断建立索引后是否真的如预期那样改善了数据库性能。

二、 根据列的特征来创建索引。

列的特点不同，索引创建的效果也不同。数据库管理员需要了解为哪些列创建索引可以起到事倍功半的效果。同时也需要了解为哪些列创建索引反而起到的是事倍功半的效果。这有利于他们了解到底给为怎么样的字段建立索引。

根据笔者的经验，往往为如下特征的列创建索引能够起到比较明显的效果。如对于一些重复内容比较少的列，特别是对于那些定义了唯一约束的列。在这些列上建立索引，往往可以起到非常不错的效果。如对于一些null值的列与非Null值的列混合情况下，如果用户需要经常查询所有的非Null值记录的列，则最好为其设置索引。如果经常需要多表连接查询，在用与连接的列上设置索引可以达到事半功倍的效果。

可见，索引设置的是否恰当，不仅跟数据库设计架构有关，而且还跟企业的经济业务相关。为此，对于一些套装软件，虽然一开始数据库管理员已经做了索引的优化工作。但是随着后来经济数据的增加，这个索引的效果会越来越打折扣。这主要是因为记录的表化影响到了索引优化的效果。所以笔者建议各位数据库管理员，即使采用的是大牌软件公司的套装软件，也需要隔一段时间，如一年，对数据库的索引进行优化。该去掉的去掉，该调整的调整，以提高数据库的性能。

如在数据库中有一张表是用来保存用户信息的。其中有个字段身份z号码，这是一个唯一的字段。在数据库设计时，给这个字段创建了索引。但是当这个数据库投入使用之后，用户不怎么输入用户的身份z号码。而且平时也基本不按这个号码来进行查询。当记录月来月多时，这个身份z号码上的索引字段不但不能够改善数据库的查询性能，反而成了鸡肋。对于这些有很多NULL值的列，而且不会经常查询所有的非NULL值记录的列，数据库管理员要下决心，即使清除这些列上的索引。

所以说索引的优化与调整是一个动态的过程，并不是说数据库设计好之后就不需要经过调整。数据库管理员往往需要根据记录的变化情况，来进行适当的变更。以提高索引的效果。

三、 在一个表上创建多少索引合适?

虽然说，在表上创建索引的数量没有限制，但是决不是越多越好。也就是说，在创建索引这项事情上，1+1〉2往往不成立。有时候，创建索引越多，其可能会得到适得其反的效果。那么在一个表上，到底给创建多少索引合适呢?这个没有一个明确的标准。而是需要数据库管理员根据实际的用途以及数据库中记录的情况，来进行判断。

通常来说，表的索引越多，其查询的速度也就越快。但是，表的更新速度则会降低。这主要是因为表的更新(如往表中插入一条记录)速度，反而随着索引的增加而增加。这主要是因为，在更新记录的同时需要更新相关的索引信息。为此，到底在表中创建多少索引合适，就需要在这个更新速度与查询速度之间取得一个均衡点。如对于一些数据仓库或者决策型数据库系统，其主要用来进行查询。相关的记录往往是在数据库初始化的时候倒入。此时，设置的索引多一点，可以提高数据库的查询性能。同时因为记录不怎么更新，所以索引比较多的情况下，也不会影响到更新的速度。即使在起初的时候需要导入大量的数据，此时也可以先将索引禁用掉。等到数据导入完毕后，再启用索引。可以通过这种方式来减少索引对数据更新的影响。相反，如果那些表中经常需要更新记录，如一些事务型的应用系统，数据更新 *** 作是家常便饭的事情。此时如果在一张表中建立过多的索引，则会影响到更新的速度。由于更新 *** 作比较频繁，所以对其的负面影响，要比查询效率提升要大的多。此时就需要限制索引的数量，只在一些必要的字段上建立索引。

笔者在平时数据库优化时，往往会根据这些表的用途来为列设置索引。可以查询相关的动态视图，看看对于这张表的 *** 作，是更新 *** 作(包括更新、删除、插入等等)占的比例大，还是查询 *** 作占的比例大。当过多的索引已经影响到更新 *** 作的速度时，则数据库管理员就需要先禁用某些索引，以提高数据库的性能。

总之，在适当的表、适当的列上建立适当的索引。这一句话包含的意思有很多，以上内容只是一部分内容。俗话说，师傅领进门，修行靠自身。笔者在这里指能够点到为止。一些具体的索引优化内容还是需要各位读者在日常工作中去体会与总结

其实索引的好坏还和你的查询语句有关系,就是where后边的列有关.如果两者协调不好的话,同样应用索引也得不到什么好处.下边的文章希望对你有益:

索引的设计

A:尽量避免表扫描检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。下面的两个条件可以提高索引的优化查询性能！第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能例如：下面的例子用了pubs数据库。

　SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'按下面几个列上建立的索引将会是对优化器有用的索引

au_lname

au_lname, au_fname而在下面几个列上建立的索引将不会对优化器起到好的作用

au_address

au_fname, au_lname考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的

histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。有用的索引会提高select语句的性能，包括insert,uodate,delete。但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index

5000 Nonclustered index

20 Clustered index

3 No index

镞索引和非镞索引的选择

<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读 *** 作，因此镞索引常常能加速这样的 *** 作。在至少有一个索引的表中，你应该有一个镞索引。在下面的几个情况下，你可以考虑用镞索引：例如：某列包括的不同值的个数是有限的（但是不是极少的）顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行 *** 作的列上。

select * from sales where ord_date between Ƌ/1/93' and ƌ/1/93'例如：对查询时返回大量结果的列可以使用镞索引。

SELECT * FROM phonebook WHERE last_name = 'Smith'

当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。在有很多不同值的列上可以考虑使用非镞索引例如：一个part_id列在一个part表中select * from employee where emp_id = 'pcm9809f'查询语句中用order by子句的列上可以考虑使用镞索引

三、查询语句的设计

SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。例如下面的例子，select qty from sales where stor_id=7131是很有效的比下面这个无限制的查询select qty from sales避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。这时多索引是没有用的。

For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in

the pubs database,下面这个query语句利用了au_lname上的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'

AND au_fname = 'Johnson'

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_fname = 'Johnson'

---