hw6-impl

A.聚簇索引效率高的原因是他是按照数据在磁盘上的物理存储顺序排列的，b+树在磁盘上直接顺序读写效率远远高于随机读写。此外，聚簇索引的叶子节点包含实际的数据行，这样可以减少磁盘I/O操作，提高查询效率。聚簇索引还有助于减少数据页的分裂，因为它按照索引键的顺序存储数据，插入和更新操作更不容易引起数据页的重组。

B.使用LONGBLOB, VARCHAR有长度最大限制,默认是64KB, 而图书封面图像base64编码之后很可能会超过这个限制,此外还有效率问题, BLOB类型不需要字符集转换, 对图片类型的二进制数据字符集转换没什么意义

C. 建立复合索引的SQL语句可能如下所示： CREATE INDEX book_author_title_date_idx ON books (author ASC, title ASC, publish_date DESC);

在构建复合索引时，字段的选择和顺序通常基于查询中使用的WHERE子句的条件。索引中的第一个字段应该是最常用于过滤的列，且具有高选择性（即列中的不同值的数量与表中总行数的比例）。如果查询中经常使用某个字段进行排序，那么该字段可以放在索引的后面，并根据需要选择升序或降序。在书籍搜索这个例子中，author, title和日期都是区分度高且容易作为筛选条件检索。

D. 自增主键，UUID损耗空间较大, 且纯粹的UUID会损失自增的特性, 使得磁盘上聚簇索引的效率下降, 不适合范围查询。在我的项目之中书籍数量并没有到需要分库分表才能装得下,所以需要分布式的ID独立性的情况,自增id在时间和空间上都有优势。并且后续ID缓存分析等,作为连续数字的ID相较uuid也更容易去和bitmap等集成

E. InnoDB和MyISAM两种存储引擎的主要差异包括：

1. 事务支持：InnoDB支持事务处理，而MyISAM不支持。
2. 锁机制：InnoDB支持行级锁，而MyISAM使用表级锁。
3. 外键支持：InnoDB支持外键约束，MyISAM不支持。
4. 崩溃恢复：InnoDB提供事务日志来支持崩溃恢复，MyISAM没有这种机制。
5. 存储结构：InnoDB的表和索引存储在一起，而MyISAM的索引和数据是分开存储的。
6. 性能：MyISAM在读取密集型操作中表现更好，InnoDB在写入密集型操作中表现更好。
7. 空间使用：MyISAM支持压缩表，可以节省磁盘空间，InnoDB不支持压缩。
8. 索引类型：InnoDB支持B-tree和全文索引，MyISAM也支持B-tree和全文索引，但不支持哈希索引。
9. 表行数：MyISAM存储表的行数，InnoDB不存储表的行数，需要全表扫描来计算