我想在包含阿拉伯文字数据的LONGBLOB字段上执行搜索。例如，你如何搜索“هذه«الأولوياتالدواوينية»ف”？
表格字段的值为3313537353B2623313630363B2623313631303B202623313630343B2623313537353B2623313630363B202623313539303B2623313538313B2623313537353B2623313631303B2623313537353B2623313630373B2623313630353B2026;但是，如果我检索阿拉伯文字值并在网页上显示，它会显示正确的阿拉伯字符。
如果我将字段的数据类型从LONGBLOB更改为LONGTEXT，是否会影响我存储的阿拉伯语内容文字？我在该表中有近1500条记录。
答案 0 :(得分：1)
了解字符与编码之间的区别非常重要。例如，字符ن将以非常不同的字节depending on its encoding存储。例如，如果使用IBM1097代码页进行编码，则它将由单字节0xcc表示，但如果使用UTF-16编码，则由四字节序列0xfefffee5表示。更糟糕的是，有时相同的字符可以在相同的编码中以多种方式表示。
除非MySQL知道使用了哪种编码，否则它将无法对您需要的排序进行文本比较（虽然它可以执行二进制搜索以搜索相同的字节序列，但这会赢得' t应用您想要的归类 -ie如何比较字符串，例如不区分大小写，或表示相同字符的不同字节序列。）
因此，您必须在执行搜索时向MySQL提供编码信息，或者让MySQL从首次接收数据的那一刻开始跟踪它（即通过将数据存储在字符串类型列而不是二进制文件中 - 型一）。
很多更常见（实际上我强烈建议你）将文本数据存储在字符串类型的列中。 LONGTEXT是一种可能性，但可能对您的需求有些过分：它可以存储高达4GiB的数据！也许TEXT或VARCHAR（最多可以容纳64KiB）或MEDIUMTEXT（最高16MiB）更合适？
一旦被理解为字符数据，MySQL就可以使用String Comparison Functions或Regular Expressions来搜索文本。例如：
SELECT * FROM mytable WHERE textcolumn LIKE '%هذه «الأولويات الدواوينية» ف%';
这将搜索mytable任何记录，其textcolumn字段包含（根据其整理）指定字符串中的任何位置。
您必须首先了解现有数据的编码格式是否存储在LONGBLOB列中（这将是原始客户端在插入/更新数据时使用的编码）。
然后您可以将其转换为字符串类型列而不会出现问题 - 但请注意，如果记录之间存在差异，则必须根据具体情况管理每条记录的转换（但您也会遇到此问题）无论如何，在检索当前数据时都是同样的问题）。例如，如果数据使用UTF-8编码，您可以将列转换为TEXT，如下所示：
ALTER TABLE mytable MODIFY textcolumn TEXT CHARACTER SET utf8;
请注意，您必须确保为您的客户正确配置connection character set，以确保在发送/检索字符串数据时发生任何必要的转换。
答案 1 :(得分：0)
以下是我认为可能的解决方案：
保留longblob：如果要搜索文本的全部内容，可以随时执行MD5总和（或任何其他哈希算法...对您有用的任何内容） longblob并搜索。你也可以索引这个MD5列，这样你就可以进行超快速搜索，如果你把它作为longint或其他东西。
此方法的一个问题是您必须知道整个文本内容才能找到记录。一种可能的解决方案是使用longblob提供链接到表中记录的主题令牌，您可以将其存储在单独的表中并进行搜索。然后，您可以从longblob表中返回与标记匹配的行。一个例子是，如果你有一些文章谈论电影，剧院，评论家和演员你将为“电影”，“剧院”，“评论家”和“演员”创建令牌，那么将它们存储在令牌表中包含文章的longblob表条目的外键，然后当用户搜索“movie”和/或“crit”和/或等时，您将返回longblob表中的那一行，因为它匹配那些特定的标记。这应该仍然可以快速搜索。
更改为longtext：如果转换为使用longtext，它将为您提供更好的搜索功能（但速度更慢），因为您可以在内部进行搜索。如果是我，我会创建一个新表，其中longtext作为主字段的类型，并编写一个脚本，从blob中读取阿拉伯数据，然后将其作为文本写入新表。如果您确保格式正确等，则不应损坏您的数据。我不确定是否只是简单地转换它会破坏它...你总是可以做一个测试用例，你用一个longblob创建一个表，用一些阿拉伯语文本填充它，然后将列转换为长文本和看看会发生什么。