小编dna*_*nag的帖子

TLDR:有谁知道具体的情况下,除了下面所示的一个,其中PDO::exec(),PDO::query(),PDO::prepare(),或PDOStatement::execute()可返回尽管没有引发异常错误,PDO::ATTR_ERRMODE被设置为PDO::ERRMODE_EXCEPTION？

我正在尝试决定是否要为我前面编写的每个数据库查询添加false检查,或者这是多余的.

编辑:我目前只使用MySQL,但如果可移植性是一个因素,这可能足以作出决定.PDO::ATTR_EMULATE_PREPARES => FALSE如果重要,我会使用.

这是我提到的具体情况.如果您准备一个包含0个或多个占位符(任一类型)的语句,然后提供一个参数数组,PDOStatement::execute()其元素多于占位符,false则返回时不会抛出异常.请注意,如果PDOStatement::bindValue()使用,则执行成功(并且只有额外绑定失败).使用比占位符少的参数会引发异常,无论参数是通过数组提供给execute函数还是使用PDOStatement::bindValue()/ 绑定PDOStatement::bindParam().

// Execute returns false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config");
if($so->execute(['Test']) === FALSE) echo '1. False returned <br />';   

// Execute does not return false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config");
if($so->bindValue(1, 'Test') === FALSE) echo '2. Binding failed <br />';
if($so->execute() === …

对于有国际支持的网站,我在大多数表格和列中使用utf8mb4字符集和utf8mb4_unicode_ci排序规则.性能不是最重要的,各种语言的准确排序很重要.

我理解utf8mb4_general_ci和utf8mb4_unicode_ci排序规则如何与重音字符进行比较,即:

SELECT column FROM table WHERE column='abad';

将返回'abad'和'abád'

在研究MySQL中的utf8支持时,我遇到了非二进制utf8___校对的假设问题.http://mzsanford.com/blog/mysql-and-unicode/上的页面描述了在某些更新中未保存更改的问题.他说'在更新记录时,似乎MySQL(或至少InnoDB)在更新记录之前检查是否相等.由于整数版本认为只有重音更改是相同的,因此MySQL会跳过写入(这会节省I/O开销)并返回成功,因为它认为它优化了写入而不是失败."

我将其解释为:如果您尝试更新仅在字段的重音符号中进行更改的记录,则它将无法正确更新(因为MySQL认为它已经匹配).但我无法复制这个.我创建了一个简单的测试用例:

CREATE DATABASE test_utf8 
    CHARACTER SET utf8mb4 
    COLLATE utf8mb4_unicode_ci;

USE test_utf8;

CREATE TABLE test (
    id MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT, 
    text VARCHAR(300) NOT NULL, 
    PRIMARY KEY (id)
) ENGINE = INNODB;

INSERT INTO test (text) VALUES ('abád');

UPDATE test SET text='abad' WHERE id=1;

但是,这会正确更新值(尽管只有一个字符的重音更改).这可能只是旧版MySQL中的一个问题吗？或者这个问题是否会在略有不同的情况下出现？

如果你有时间阅读我关于这个主题的一些概念的一些说明,看看我是否有任何误解,我也将不胜感激.如果它没有错误,也许它对某人来说是有用的信息.

MySQL的utf8字符集不提供真正的utf8支持,因为字符只有1-3个字节.要获得真正的utf8支持,您可能需要使用utf8mb4.

一般来说,utf8mb4_unicode_ci在语言适当的排序方面会更准确,但与使用utf8mb4_general_ci相比,会有轻微的性能损失.

如果某些列不需要排序,并且将使用比较/相等检查,则应使用utf8mb4_bin,因为它会稍快一些.

在utf8mb4_general_ci和utf8mb4_unicode_ci排序规则中,重音字符被视为相等.因此,对于必须具有唯一值(例如主键)的列,这是一个错误的排序规则选择.在这种情况下,应该使用utf8mb4_bin.如果一个字段需要具有唯一性的重音感知,但也需要在某个时候进行语言排序,它可以存储为utf8mb4_bin,并且您可以在排序时在查询中使用collat​​e子句.例如:

SELECT column FROM table ORDER BY column COLLATE utf8mb4_unicode_ci;

这将导致排序语言排序,尽管其内部存储在二进制排序规则中.这将影响性能,因为字段的整理决定了它的索引方式.查询的性能差异类似于对未索引列与索引列进行排序时的性能差异.

默认情况下,utf8mb4_unicode_ci或utf8mb4_general_ci排序规则下的搜索不会重音,因此搜索'abad'会返回'abad'和'abád'.因此,如果您需要重音感知搜索,则必须将列的排序规则设置为utf8mb4_binary(如果所有搜索都是重音敏感的)或在查询中使用collat​​e子句(如果您希望大多数搜索都是重音盲).由于utf8mb4_bin排序规则区分大小写,因此如果您需要不区分大小写但需要重音的搜索,则还需要修改查询.例如(假设您的搜索词已经在服务器端脚本语言中变成小写):

(Assuming the data is stored with a …