使用可以在一行中存储超过65,535字节的AWS数据库

Question

我有一个MySQL梭形表，大约有150个字段，其中大多数是文本类型。

1. 如果我想连续存储超过65,535个字符，是否可以使用Amazon的AWS数据库进行存储？如果是的话，是哪种数据库？RDS？
2. 我使用的是半VPS类型的托管公司，它的应用程序在普通PHP连接到这个数据库。是否可以只将数据库迁移到AWS，并使应用程序在我的托管公司上运行？(我应该能够从我的主机的PHP应用程序连接到这个AWS数据库。

Answer 1

(寻址Q1)

有很多办法可以解决膨胀的柱子。我们来解决这个问题。

表的ROW_FORMAT是什么？DYNAMIC和COMPACT的工作方式不同。

他们都需要成为TEXT吗？或者一些可以是低限值的VARCHAR？(例如：name TEXT -> name VARCHAR(60))

考虑“垂直分区”。这是将一个表分成两个表的地方--在每个表中放置一些列。他们将拥有相同的PRIMARY KEY (除了两者都不是AUTO_INCREMENT)。

这些列中是否有重复值？如果是这样的话，请考虑正常化。(例如，country TEXT -> country_code CHAR(2) CHARACTER SET ascii，其值为“US”、“ES”、“UK”、“IN”。)

你在列上放过数组吗？那是不-不。将这组列转换为相关表中的行。(如home_phone，work_phone，传真，手机)

请向SHOW CREATE TABLE提供实际的列名；我们可能有更多的提示。(我上面的一些建议可能非常明显。)

在看了模式之后..。

我看到了一堆听起来像是货币或其他数字内容的列，但都是在VARCHAR(25)中；请考虑更改为INT或其他数字数据类型。

我看到了大约80 TEXT和VARCHAR。这确实强调了InnoDB中的一些内置限制。但是，他们可以，也需要，在这方面发挥作用：

方案A:垂直分区--将FR、COP、PP、Customer等划分为几个额外的表。使用JOIN重新收集数据.

计划B:将大多数列抛到一个大型JSON文本列中。或者可能是FR，或者是客户，等等。大多数应用语言都可以很容易地解析JSON。

因为您只有一个索引(在id上)，所以我想没有搜索表的必要了吗？其他一些列，比如userID和name，应该保存在它们自己的列中，并且可能会被索引。