如何使用超过 250,000 行正确构建 "products" table？
How do I structure my "products" table correctly with over 250,000 rows?
问题
我找到了一份小工作，为一家电子分销商开发在线报价系统。他有大约 50 万个零件 - 一个小螺丝被认为是零件，一个小 LED 等。所以零件很多。
一个重要提示：这只是一个 RFQ（询价）。没有客户端价格、总计价格或任何与金钱有关的价格。只是收集零件号列表发送给我的客户。
我不得不从多个来源（供应商网站、扫描的纸质目录、Excel 电子表格、CSV 文件，甚至一些 JSON 文件收集零件数据。这很累人，但我搞定了。
结果
一开始很困惑。我有几十个产品类别，有些产品具有 如此之多的 属性，这些属性对于任何其他产品都是不常见的。我可以看到这个项目变得非常复杂，考虑到我什至以 900 美元的价格出价，我不得不以某种方式简化它。
这是我想出来的，并得到了客户的认可。
当前列
+--------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+--------------+------+-----+---------+-------+
| Datasheets | varchar(128) | YES | | NULL | |
| Image | varchar(85) | YES | | NULL | |
| DigiKey_Part_Number | varchar(46) | YES | | NULL | |
| Manufacturer_Part_Number | varchar(47) | YES | | NULL | |
| Manufacturer | varchar(49) | YES | | NULL | |
| Description | varchar(34) | YES | | NULL | |
| Quantity_Available | int(11) | YES | | NULL | |
| Minimum_Quantity | int(11) | YES | | NULL | |
+--------------------------+--------------+------+-----+---------+-------+
因此所有产品都适合此页面模板（屏幕截图中底部的菜单有误）：
关闭自动完成 Table?
在设计的早期，我实现了一个很好的自动完成功能：
BUT .. given the number of products in the table, is this even
practical anymore ???
最终产品数量： 223,347
我需要对 PRODUCTS table 进行哪些更改，以便查询 table 不会花很长时间？
这些是应用程序将进行的唯一查询（不确定此信息是否有助于您的解决方案建议）...
按类别获取所有产品：
Select * 来自类别 = 'semiconductors'
的产品
获取单品：
Select * 来自 Manufacturer_Part_Number = '12345'
的产品
按类别获取产品数量
我认为这三个实际上涵盖了我需要做的一切。可能还有几个，但不会很多。
收盘中...
有没有一种方法可以用 223000 条记录“索引”这个 table，从而可以高效地按一列或多列进行搜索？
我是数据库设计的新手，我知道我确实需要索引一些东西，但是......什么？？？
感谢您花时间看这篇文章post。
此致，
约翰
必须列出查询才能回答您的问题。感谢包括他们。
INDEX(category)
INDEX(Manufacturer_Part_Number)
但我建议您的第二个查询也应该包括 Manufacturer。那这样就更好了:
INDEX(Manufacturer, Manufacturer_Part_Number)
一切NULL？似乎不太可能。
（我做过像你这样的工作；我无法想象只出价 900 美元就可以完成所有这些刮擦。）
当一个类别或制造商有上千个项目时，你会怎么做？带有 thousand-item 列表的 UI 糟透了。
关于如何处理“如此多的属性”，我建议 http://mysql.rjweb.org/doc.php/eav（我应该向你收取 899 美元用于该文档的研究。开玩笑。）
他们不需要其他查找，比如“闪存驱动器”，需要匹配“FLASH DRV”吗？
223K 行 -- 没问题。 VARCHARs 好像太短了；他们是基于数据吗？
而 table 需要一个 PRIMARY KEY。
问题
我找到了一份小工作，为一家电子分销商开发在线报价系统。他有大约 50 万个零件 - 一个小螺丝被认为是零件，一个小 LED 等。所以零件很多。
一个重要提示：这只是一个 RFQ（询价）。没有客户端价格、总计价格或任何与金钱有关的价格。只是收集零件号列表发送给我的客户。
我不得不从多个来源（供应商网站、扫描的纸质目录、Excel 电子表格、CSV 文件，甚至一些 JSON 文件收集零件数据。这很累人，但我搞定了。
结果
一开始很困惑。我有几十个产品类别，有些产品具有 如此之多的 属性，这些属性对于任何其他产品都是不常见的。我可以看到这个项目变得非常复杂，考虑到我什至以 900 美元的价格出价，我不得不以某种方式简化它。
这是我想出来的，并得到了客户的认可。
当前列
+--------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+--------------+------+-----+---------+-------+
| Datasheets | varchar(128) | YES | | NULL | |
| Image | varchar(85) | YES | | NULL | |
| DigiKey_Part_Number | varchar(46) | YES | | NULL | |
| Manufacturer_Part_Number | varchar(47) | YES | | NULL | |
| Manufacturer | varchar(49) | YES | | NULL | |
| Description | varchar(34) | YES | | NULL | |
| Quantity_Available | int(11) | YES | | NULL | |
| Minimum_Quantity | int(11) | YES | | NULL | |
+--------------------------+--------------+------+-----+---------+-------+
因此所有产品都适合此页面模板（屏幕截图中底部的菜单有误）：
关闭自动完成 Table?
在设计的早期，我实现了一个很好的自动完成功能：
BUT .. given the number of products in the table, is this even practical anymore ???
最终产品数量： 223,347
我需要对 PRODUCTS table 进行哪些更改，以便查询 table 不会花很长时间？
这些是应用程序将进行的唯一查询（不确定此信息是否有助于您的解决方案建议）...
按类别获取所有产品： Select * 来自类别 = 'semiconductors'
的产品获取单品： Select * 来自 Manufacturer_Part_Number = '12345'
的产品按类别获取产品数量
我认为这三个实际上涵盖了我需要做的一切。可能还有几个，但不会很多。
收盘中...
有没有一种方法可以用 223000 条记录“索引”这个 table，从而可以高效地按一列或多列进行搜索？
我是数据库设计的新手，我知道我确实需要索引一些东西，但是......什么？？？
感谢您花时间看这篇文章post。
此致，
约翰
必须列出查询才能回答您的问题。感谢包括他们。
INDEX(category)
INDEX(Manufacturer_Part_Number)
但我建议您的第二个查询也应该包括 Manufacturer。那这样就更好了:
INDEX(Manufacturer, Manufacturer_Part_Number)
一切NULL？似乎不太可能。
（我做过像你这样的工作；我无法想象只出价 900 美元就可以完成所有这些刮擦。）
当一个类别或制造商有上千个项目时，你会怎么做？带有 thousand-item 列表的 UI 糟透了。
关于如何处理“如此多的属性”，我建议 http://mysql.rjweb.org/doc.php/eav（我应该向你收取 899 美元用于该文档的研究。开玩笑。）
他们不需要其他查找，比如“闪存驱动器”，需要匹配“FLASH DRV”吗？
223K 行 -- 没问题。 VARCHARs 好像太短了；他们是基于数据吗？
而 table 需要一个 PRIMARY KEY。