在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。
在海宁等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计、成都做网站 网站设计制作按需开发网站,公司网站建设,企业网站建设,品牌网站制作,成都全网营销,成都外贸网站制作,海宁网站建设费用合理。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。
问题在这个地方，去掉索引长度 （191），就可以使用到索引。
这里使用的两边%，同时字段符合覆盖索引，但是设置了前缀索引，因此查询用不到索引。
查到的一个说法：
MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引，也不能把它们用作覆盖索引(Covering Index)。
去掉索引长度后的执行结果
1、关联的字段又空值
2、使用了大于、小于、in等关键字进行关联
当你source字段唯一性不高，例如你90w数据，里面source字段来来去去就那么十几个值，这种情况下影响结果集巨大，就会全表扫描。这种情况全表扫描还要快于利用索引，只要理解索引的本质不难明白MySQL为何不使用索引。
极端点的情况，90万的数据，source只有0和1两个值，利用索引要先读索引文件，然后二分查找，找到对应数据的数据磁盘指针，再根据读到的指针再读磁盘上对应的数据数据，影响结果集45万。这种情况，和直接全表扫描那个快显而易见。
如果你source字段是一个unique，就会用到索引。
如果你一定要用索引，可以用force index，不过效率不会有改善一般还会更慢就是了。
类似地，如果WHERE子句的查询条件里使用了函数(WHERE DAY(column) = …)，MySQL也将无法使用索引。在JOIN操作中(需要从多个数据表提取数据时)，MySQL只有在主键和外键的数据类型相同时才能使用索引。如果WHERE子句的查询条件里使用比较操作符LIKE和REGEXP，MySQL只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。 比如说， 如果查询条件是LIKE ‘abc%’，MySQL将使用索引；如果查询条件是LIKE ‘%abc’，MySQL将不使用索引。在ORDER BY操作中，MySQL只有在排序条件不是一个查询条件表达式的情况下才使用索引。 (虽然如此，在涉及多个数据表查询里，即使有索引可用，那些索引在加快 ORDER BY方面也没什么作用) 如果某个数据列里包含许多重复的值，就算为它建立了索引也不会有很好的效果。 顶一下(0)0%踩一下(0)0%
