从文档中,它声明:
CSV存储引擎使用逗号分隔将数据存储在文本文件中值格式。
这样做有什么好处?以下是我能想到的:
- 您可以使用简单的文本编辑器编辑CSV文件(但是,您可以使用
SELECT INTO OUTFILE
轻松导出数据) - 可以轻松导入电子表格程序
- 重量轻,性能可能更好(胡乱猜测)
有哪些缺点?
- 无索引
- 无法分区
- 无交易记录
- 不能有NULL值
考虑到这个(非详尽的)优点和缺点列表,在什么实际情况下,我应该考虑使用CSV存储引擎而不是其他存储引擎?
我很少使用CSV存储引擎。然而,我发现它的一个有用场景是批量数据导入。
- 创建一个包含与我的输入CSV文件匹配的列的表
- 在mysql之外,只需使用shell提示符,
mv
将CSV文件写入mysql数据字典,覆盖属于我刚刚创建的表的.CSV文件 ALTER TABLE mytable ENGINE=InnoDB
瞧!使用DDL而不是INSERT或LOAD data一步导入一个巨大的CSV数据文件。
诚然,它不如INSERT或LOAD DATA灵活,因为您不能对单个列执行NULL或自定义重写,也不能使用任何"替换"或"忽略"功能来处理重复值。但是,如果您有一个正是您想要导入的输入文件,则可以使导入变得非常容易。
这是一个tad的小技巧,但从MySQL 8开始,假设你事先知道数据结构并在基于CSV的模式目录中拥有权限,你可以在MySQL中创建表定义,然后用数据文件的符号链接覆盖数据目录中生成的CSV表文件:
mysql --execute="CREATE TABLE TEST.CSV_TEST ( test_col VARCHAR(255) ) ENGINE=CSV;"
ln -sf /path/to/data.file /var/lib/mysql/TEST/CSV_TEST.CSV
这里的一个优点是,这完全消除了运行导入操作的需要(通过LOAD DATA INFOILE等),因为它允许MySQL从符号链接文件中直接读取,就好像它是表文件一样。
CSV引擎固有缺陷之外的缺陷:
- 表将包含标题行(若有)(您需要从读取操作中将其过滤掉)
- INFORMATION_SCHEMA中的表元数据将不使用此方法进行更新,只显示运行初始DDL的CREATE_TIME
请注意,这种方法显然更倾向于READ操作,尽管可以使用SELECT在命令行上执行更新/插入操作。。。INTO OUTFILE,然后复制到源文件上/附加源文件。