①.,每个数据库对应一个文件夹,文件夹名和库名相同；
frm文件：存储的是表结构信息.
ibd文件：存储的是表里的数据、索引等.
多选框是checkbox好吧...
一般的做法都是用个符号分割,然后组成字符串,作为字符串字段保存在数据库里.
如果选项很少的话,也可以考虑每个选项单独一个字段保存.
索引的目的在于提高查询效率,可以类比字典,如果要查"mysql"这个单词,我们肯定需要定位到m字母,然后从下往下找到y字母,再找到剩下的sql.如果没有索引,那么你可能需要把所有单词看一遍才能找到你想要的.
①索引的优点
这个查询的结果应该是1000行,每个数据行包含三个相等的值.如果在没有索引的情况下处理这个查询,那么如果我们不对这些表进行全部地扫描,我们是没有办法知道哪些数据行含有哪些值的.所以呢你必须尝试所有的组合来查找符合WHERE条件的记录.可能的组合的数量是1000 x 1000 x 1000（10亿！）,它是匹配记录的数量的一百万倍.这就浪费了大量的工作.这个例子显示,如果没有使用索引,随着表的记录不断增长,处理这些表的联结所花费的时间增长得更快,导致性能很差.我们可以通过索引这些数据表来显著地提高速度,因为索引让查询采用如下所示的方式来处理：
①.．选择表t1中的第一行并查看该数据行的值.
-
首先,索引加快了检索的速度,但是减慢了插入和删除的速度,同时还减慢了更新被索引的数据列中的值的速度.也就是说,索引减慢了大多数涉及写操作的速度.发生这种现象的原因在于写入一条记录的时候不但需要写入数据行,还需要改变所有的索引.数据表带有的索引越多,需要做出的修改就越多,平均性能的降低程度也就越大.在本文的"高效率载入数据"部分中,我们将更细致地了解这些现象并找出处理方法.
其次,索引会花费磁盘空间,多个索引相应地花费更多的磁盘空间.这可能导致更快地到达数据表的大小限制：
- 对于MyISAM表,频繁地索引可能引起索引文件比数据文件更快地达到最大限制.
- 对于BDB表,它把数据和索引值一起存储在同一个文件中,添加索引引起这种表更快地达到最大文件限制.
- 在InnoDB的共享表空间中分配的所有表都竞争使用相同的公共空间池,所以呢添加索引会更快地耗尽表空间中的存储.但是,与MyISAM和BDB表使用的文件不同,InnoDB共享表空间并不受操作系统的文件大小限制,因为我们可以把它配置成使用多个文件.只要有额外的磁盘空间,你就可以通过添加新组件来扩展表空间.
使用单独表空间的InnoDB表与BDB表受到的约束是一样的,因为它的数据和索引值都存储在单个文件中.
这些要素的实际含义是：如果你不需要使用特殊的索引帮助查询执行得更快,就不要建立索引.
假设你已经知道了建立索引的语法,但是语法不会告诉你数据表应该如何索引.这要求我们考虑数据表的使用方式.这一部分指导你如何识别出用于索引的备选数据列,以及如何最好地建立索引：
用于搜索、排序和分组的索引数据列并不仅仅是用于输出显示的.换句话说,用于索引的最好的备选数据列是那些出现在WHERE子句、join子句、ORDER BY或GROUP BY子句中的列.仅仅出现在SELECT关键字后面的输出数据列列表中的数据列不是很好的备选列：
当然,显示的数据列与WHERE子句中使用的数据列也可能相同.我们的观点是输出列表中的数据列本质上不是用于索引的很好的备选列.
- 较短的值可以更快地进行比较,所以呢索引的查找速度更快了.
- 较小的值导致较小的索引,需要更少的磁盘I/O.
- 使用较短的键值的时候,键缓存中的索引块（block）可以保存更多的键值.MySQL可以在内存中一次保持更多的键,在不需要从磁盘读取额外的索引块的情况下,提高键值定位的可能性.
对于InnoDB和BDB等使用聚簇索引（clustered index）的存储引擎来说,保持主键（primary key）短小的优势更突出.聚簇索引中数据行和主键值存储在一起（聚簇在一起）.其它的索引都是次级索引；它们存储主键值和次级索引值.次级索引屈从主键值,它们被用于定位数据行.这暗示主键值都被复制到每个次级索引中,所以呢如果主键值很长,每个次级索引就需要更多的额外空间.
你可以索引CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT数据列的前缀.
使用最左（leftmost）前缀.建立多列复合索引的时候,你实际上建立了MySQL可以使用的多个索引.复合索引可以作为多个索引使用,因为索引中最左边的列集合都可以用于匹配数据行.这种列集合被称为"最左前缀"（它与索引某个列的前缀不同,那种索引把某个列的前面几个字符作为索引值）.
假设你在表的state、city和zip数据列上建立了复合索引.索引中的数据行按照state/city/zip次序排列,所以呢它们也会自动地按照state/city和state次序排列.这意味着,即使你在查询中只指定了state值,或者指定state和city值,MySQL也可以使用这个索引.所以呢,这个索引可以被用于搜索如下所示的数据列组合：
state, city, zip state, city state
不要过多地索引.不要认为"索引越多,性能越高",不要对每个数据列都进行索引.我们在前面提到过,每个额外的索引都会花费更多的磁盘空间,并降低写操作的性能.当你修改表的内容的时候,索引就必须被更新,甚至可能重新整理.如果你的索引很少使用或永不使用,你就没有必要减小表的修改操作的速度.此外,为检索操作生成执行计划的时候,MySQL会考虑索引.建立额外的索引会给查询优化器增加更多的工作量.如果索引太多,有可能（未必）出现MySQL选择最优索引失败的情况.维护自己必须的索引可以帮助查询优化器来避免这类错误.
如果你考虑给已经索引过的表添加索引,那么就要考虑你将增加的索引是否是已有的多列索引的最左前缀.如果是这样的,不用增加索引,因为已经有了（例如,如果你在state、city和zip上建立了索引,那么没有必要再增加state的索引）.
让索引类型与你所执行的比较的类型相匹配.在你建立索引的时候,大多数存储引擎会选择它们将使用的索引实现.例如,InnoDB通常使用B树索引.MySQL也使用B树索引,它只在三维数据类型上使用R树索引.但是,MEMORY存储引擎支持散列索引和B树索引,并允许你选择使用哪种索引.为了选择索引类型,需要考虑在索引数据列上将执行的比较操作类型：
- 对于散列（hash）索引,会在每个数据列值上应用散列函数.生成的结果散列值存储在索引中,并用于执行查询.散列函数实现的算法类似于为不同的输入值生成不同的散列值.使用散列值的好处是散列值比原始值的比较效率更高.散列索引用于执行=或=操作等精确匹配的时候速度非常快.但是对于查询一个值的范围效果就非常差了：
- B树索引可以用于高效率地执行精确的或者基于范围（使用操作、=、=、=、、、!=和BETWEEN）的比较.B树索引也可以用于LIKE模式匹配,前提是该模式以文字串而不是通配符开头.
如果你使用的MEMORY数据表只进行精确值查询,散列索引是很好的选择.这是MEMORY表使用的默认的索引类型,所以呢你不需要特意指定.如果你希望在MEMORY表上执行基于范围的比较,应该使用B树索引.为了指定这种索引类型,需要给索引定义添加USING BTREE.例如：
如果你希望执行的语句的类型允许,单个MEMORY表可以同时拥有散列索引和B树索引,即使在同一个数据列上.
有些类型的比较不能使用索引.如果你只是通过把值传递到函数（例如STRCMP()）中来执行比较操作,那么对它进行索引就没有价值.服务器必须计算出每个数据行的函数值,它会排除数据列上索引的使用.
使用慢查询（slow-query）日志来识别执行情况较差的查询.这个日志可以帮助你找出从索引中受益的查询.你可以直接查看日志（它是文本文件）,或者使用mysqldumpslow工具来统计它的内容.如果某个给定的查询多次出现在"慢查询"日志中,这就是一个线索,某个查询可能没有优化编写.你可以重新编写它,使它运行得更快.你要记住,在评估"慢查询"日志的时候,"慢"是根据实际时间测定的,在负载较大的服务器上"慢查询"日志中出现的查询会多一些.
以上就是土嘎嘎小编为大家整理的mysql多选怎么存相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！