我有一个数据库，大量用户将使用该数据库来存储随机长字符串（最多 100 个字符）。表列将是：userid、stringid 和实际的长字符串。
所以它看起来很像这样：
Userid 将是唯一的，而 stringid 对于每个用户来说都是唯一的。
该应用程序就像一个简单的待办事项列表应用程序，因此每个用户平均有 50 个待办事项。我使用 stringid 是为了让用户能够在任何给定时间删除特定任务。
我假设这个 todo 应用程序可能会在 3 年内完成 700 万个任务，这让我害怕使用 MySQL。
所以我的问题是，这是否是处理带有长字符串的大量数据的实际推荐方法（每个新任务都有一个新行）？MySQL 是适合此类项目的数据库解决方案吗？
我还没有经历过大量数据，我正在努力为遥远的未来拯救自己。
这不是“大量”数据的问题（mysql 可以很好地处理大量数据，并且 2 mio 行在任何情况下都不是“大量”）。
MySql 是一个关系型数据库。因此，如果您有可以标准化的数据，这些数据分布在许多表中，以确保每个数据点只保存一次，那么您应该使用 MySql（或 Maria，或任何其他关系数据库）。
如果您有无模式数据并且速度比一致性更重要，那么您可以/应该使用一些 NoSql 数据库。就我个人而言，我不知道待办事项列表如何从 NoSql 中受益（在这种情况下并不重要，但我想到目前为止，大多数 programmig 框架对关系数据库的支持比对 Nosql 的支持更好）。
这是一个非常简单的关系用例。我认为这里不需要 NoSQL。
您提供的表格应该可以正常工作，但是，我个人会质疑复合主键的必要性，因为您将展示这个。我可能会在 stringid 上有一个主键，只是为了强制所有记录的唯一性。而不是跨用户 ID 和字符串 ID 的复合主键。然后我会在用户 ID 上放置一个常规索引。
这样做的原因是，如果您只想通过 stringid 查询（即删除或更新），您不必总是必须跨两个字段查询以利用您的索引（或添加必须在 stringid 上添加单个索引和userid 启用每个字段的查询，这意味着我在内存和磁盘中的空间被索引占用）。
至于 MySQL 是否是正确的解决方案，这真的由您来确定。我会说 MySQL 在处理两个整数 id 字段上有 200 万行和 2 个索引的表时应该没有问题。这是假设您已分配足够的内存来将这些索引保存在内存中。当然有大量关于使用 MySQL 的信息，所以如果你只是想学习，它可能是一个不错的选择。
无论您认为什么是“大量数据”，现代数据库引擎都旨在处理大量数据。“关系还是 NoSQL？”的问题 不是关于哪个选项可以支持更多数据。不同的关系和 NoSQL 解决方案将以不同的方式处理大量数据，其中一些解决方案比其他解决方案更好。
MySQL 可以处理数百万条记录，而 SQLite 不能（至少不那么有效）。Mongo（NoSQL）试图将它的集合保存在内存（以及文件系统）中，所以我看到它在内存有限的服务器上只有不到 100 万条记录失败，尽管它提供了分片，可以帮助它更有效地扩展。
底线是：您存储的记录数量不应影响 SQL 与 NoSQL 决策，该决定应留给您将如何保存和检索数据。听起来您的数据已经标准化（例如 UserID），如果您在删除用户时也希望保持一致性（TODO 项目也被删除），那么我建议使用 SQL 解决方案。
我假设所有查询都将引用特定的用户 ID。我还假设 stringid 是内部使用的虚拟值，而不是实际的任务文本（您的随机字符串）。
使用带有复合主键的 InnoDB 表{userid, stringid}，由于聚集索引的工作方式，您将获得所需的所有性能。