大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
兄弟,primary key是主键,每个表只能有一个主键,而且数据是唯一的。\x0d\x0a可以这样写:\x0d\x0aCREATE TABLE IF NOT EXISTS `".$ctb_name."` (\x0d\x0a `id` INT(9) NOT NULL AUTO_INCREMENT PRIMARY KEY,\x0d\x0a `keyid` VARCHAR(20) NOT NULL,\x0d\x0a `key` VARCHAR(20) NOT NULL,\x0d\x0a `stauts` BOOL NOT NULL DEFAULT'0',\x0d\x0aindex `idx_status`(`status`)\x0d\x0a )ENGINE = MYISAM DEFAULT CHARSET=utf8;\x0d\x0a不过,status是bool类型的字段,只有true和false,区分度太低,没有必要加索引。\x0d\x0a\x0d\x0a索引目的是为了使查询更快,区分度小的时候不如全表扫描。
专注于为中小企业提供成都网站制作、网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业鸡东免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了上1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
字符串创建索引方式:
1、直接创建完整索引,比较占用空间。
2、创建前缀索引,节省空间,但会增加查询扫描次数,并且不能使用覆盖索引。
3、倒序存储,在创建前缀索引,用于绕过字符串本身前缀的却分度不够的问题。
4、创建hash字段索引,查询性能稳定,有额外的存储和计算消耗。
倒序存储和hash字段索引都不支持范围查询。倒序存储的字段上创建的所有是按照倒序字符串的方式排序的。hash字段的方式也只能支持等值查询。
mysql alter table SUser add index index1(email); :包含了每个记录的整个字符串
或
mysql alter table SUser add index index2(email(6)); :-对于每个记录只取前6个字节
全字段索引操作流程
使用的是 index1(即 email 整个字符串的索引结构),执行顺序是这样的:
1、从 index1 索引树找到满足索引值是’ zhangssxyz@xxx.com ’的这条记录,取得 ID2 的值;
2、到主键上查到主键值是 ID2 的行,判断 email 的值是正确的,将这行记录加入结果集;
3、取 index1 索引树上刚刚查到的位置的下一条记录,发现已经不满足 email=' zhangssxyz@xxx.com ’的条件了,循环结束。
前缀字段索引操作流程
如果使用的是 index2(即 email(6) 索引结构),执行顺序是这样的:
1、从 index2 索引树找到满足索引值是’zhangs’的记录,找到的第一个是 ID1;
2、到主键上查到主键值是 ID1 的行,判断出 email 的值不是’ zhangssxyz@xxx.com ’,这行记录丢弃;
3、取 index2 上刚刚查到的位置的下一条记录,发现仍然是’zhangs’,取出 ID2,再到 ID 索引上取整行然后判断,这次值对了,将这行记录加入结果集;
4、重复上一步,直到在 idxe2 上取到的值不是’zhangs’时,循环结束。
倒序查询和hash字段的区别
它们的区别,主要体现在以下三个方面:
1、从占用的额外空间来看,倒序存储方式在主键索引上,不会消耗额外的存储空间,而 hash 字段方法需要增加一个字段。当然,倒序存储方式使用 4 个字节的前缀长度应该是不够的,如果再长一点,这个消耗跟额外这个 hash 字段也差不多抵消了。
2、在 CPU 消耗方面,倒序方式每次写和读的时候,都需要额外调用一次 reverse 函数,而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话,reverse 函数额外消耗的 CPU 资源会更小些。
3、从查询效率上看,使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率,但是概率非常小,可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式,也就是说还是会增加扫描行数。
在实际开发中使用数据库时,难免会遇到一些大表数据,对这些数据进行查询时,有时候SQL会查询得特别慢,这时候,有经验的老师傅会告诉你,你看一下哪几个字段查的多,加一个索引就好了。
那么,怎么合理地建立索引呢?这里分享一下我的一些经验,如有不妥之处,欢迎批评指正。
1、不要盲目建立索引 , 先分析再创建
索引虽然能大幅度提升我们的查询性能,但也要知道,在你进行增删改时,索引树也要同样地进行维护。所以,索引不是越多越好,而是按需建立。最好是在一整块模块开发完成后,分析一下,去针对大多数的查询,建立联合索引。
2、使用联合索引尽量覆盖多的条件
这是说在一个慢sql里假如有五个where ,一个 order by ,那么我们的联合索引尽量覆盖到这五个查询条件,如果有必要,order by 也覆盖上 。
3、小基数字段不需要索引
这个意思是,如果一张表里某个字段的值只有那么几个,那么你针对这个字段建立的索引其实没什么意义,比如说,一个性别字段就两种结果,你建了索引,排序也没什么意思(也就是索引里把男女给分开了)
所以说,索引尽量选择基数大的数据去建立,能最大化地利用索引
4、长字符串可以使用前缀索引
我们建立索引的字段尽量选择字段类型较小的,比如一个varchar(20)和varchar(256)的,我们在20的上面建立的索引和在256上就有明显的差距(字符串那么长排序也不好排呀,唉)。
当然,如果一定是要对varchar(256)建立索引,我们可以选择里面的前20个字符放在索引树里(这里的20不绝对,选择能尽量分辨数据的最小字符字段设计),类似这样KEY index(name(20),age,job) ,索引只会对name的前20个字符进行搜索,但前缀索引无法适用于order by 和 group by。
5、对排序字段设计索引的优先级低
如果一个SQL里我们出现了范围查找,后边又跟着一个排序字段,那么我们优先给范围查找的字段设置索引,而不是优先排序。
6、如果出现慢SQL,可以设计一个只针对该条SQL的联合索引。
不过慢SQL的优化,需要一步步去进行分析,可以先用explain查看SQL语句的分析结果,再针对结果去做相应的改进。explain的东西我们下次再讲。
PS:在 select 语句之前增加 explain 关键字,MySQL 会在查询上设置一个标记,执行查询会返回执行计划的信息,而不是 执行这条SQL。