优化用户定义的自定义列

Question

我正在构建一个基于web的应用程序，它具有很高的流量和收集大量数据的潜力。这些流量中的大部分将使用数据库。数据库为MySQL InnoDB。我希望让用户能够定义自己的数据字段以及一组常见的预定义列。例如，我将有一个具有下列列的表(餐馆)：

record_id //INT PK auto_inc

record_uuid //索引存储为二进制(16)

user_uuid //索引存储为二进制(16)

restaurant_uuid //索引存储为二进制(16)

日期//索引

价格//指数

party_count //索引

评级//索引

..。

用户"A“然后添加他自己的字段，比如(chef_name，phone，table_count，phone)

而用户"B“可能添加(contract_amount、license_fee、cuisine_type)之类的字段。

我的想法是为每一个自定义字段都有多个表来保存一行数据。所以我要restaurants_extension_varchar，restaurants_extension_int和restaurants_extension_float。

这三张表的每一张看起来都是这样的：

extension_id //INT PK auto_increment

extension_uuid //索引存储为二进制(16)，被app用于更新数据值

record_id //索引INT -用作主餐馆表的键

field_identifier // TINYINT

the_data //索引varchar/int/float -取决于这是哪个表

然后，我将这些表中的每一个划分为6个分区。字段标识符将保存在该用户的内存数组中，并将该记录映射到该自定义字段的标签和页面放置数据。这些自定义字段将通过Ajax单独更新，而不是像单击多字段表单上的submit那样作为一个组进行更新。我希望这些表能容纳数百万行。我已经决定使用一个自动增量ID作为所有表的主键，加上一个UUID作为我将传递给web应用程序的应用程序ID，以防止用户操纵主键ID以尝试实现其他行。

所有自定义字段都需要可搜索。

我有两个问题。第一个是关于结构的。从纯粹的性能角度来看，这是一个很好的解决方案，还是用一行有大量列会更好。

第二个问题是关于自动增量主键ID的使用，以及将被索引的应用程序生成的uuid键。据我所理解，如果我使用uuid作为主键，它将在创建的每个索引中被复制。我不是DBA，所以如果有什么建议可以提供的话，我将非常感激。谢谢你！

Answer 1

很多人都想做你描述的事情。当数据集变大时，它们就会陷入大麻烦。

所有自定义字段都需要可搜索。

只有一个解决方案:带有“动态列”的MariaDB。讨论为什么不实用的原因，并讨论较小的解决方案：http://mysql.rjweb.org/doc.php/eav

自动增量主键ID以及将被索引的应用程序生成的uuid键

一旦表(或至少索引)太大而无法缓存，UUID/UUID将导致大量随机磁盘I/O并破坏缓存。进一步讨论(和解决办法)：http://mysql.rjweb.org/doc.php/uuid