在本系列中测试最简单的SQL模式，以评估哪些数据库可以符合分布式SQL的资格，我对许多与MySQL兼容的功能的能力印象深刻，因为参考完整性是二等公民。 TIDB通常被限定为分布式SQL，因为它基于Spanner架构。让我们尝试一下。
我正在尝试使用Tidb Cloud，并且由于有一个CHAT2Query人工智能，让我们问create the traditional EMP DEPT tables with autoincrement and referential integrity：
结果根本不错：
但是，要对本系列中的所有帖子做同样的事情，我的运行与上一篇文章相同：
use sample_data;
CREATE TABLE dept (
deptno integer NOT NULL,
dname text,
loc text,
description text,
CONSTRAINT pk_dept PRIMARY KEY (deptno asc)
);
CREATE TABLE emp (
empno integer NOT NULL auto_increment,
ename text NOT NULL,
job text,
mgr integer,
hiredate date,
sal integer,
comm integer,
deptno integer NOT NULL,
email varchar(90),
other_info json,
CONSTRAINT pk_emp PRIMARY KEY (empno),
CONSTRAINT emp_email_uk UNIQUE (email),
CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);
INSERT INTO dept (deptno, dname, loc, description)
VALUES (10, 'ACCOUNTING', 'NEW YORK','preparation of financial statements, maintenance of general ledger, payment of bills, preparation of customer bills, payroll, and more.'),
(20, 'RESEARCH', 'DALLAS','responsible for preparing the substance of a research report or security recommendation.'),
(30, 'SALES', 'CHICAGO','division of a business that is responsible for selling products or services'),
(40, 'OPERATIONS', 'BOSTON','administration of business practices to create the highest level of efficiency possible within an organization');
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno, email, other_info)
VALUES (7369, 'SMITH', 'CLERK', 7902, '1980-12-17', 800, NULL, 20,'SMITH@acme.com', '{"skills":["accounting"]}'),
(7499, 'ALLEN', 'SALESMAN', 7698, '1981-02-20', 1600, 300, 30,'ALLEN@acme.com', null),
(7521, 'WARD', 'SALESMAN', 7698, '1981-02-22', 1250, 500, 30,'WARD@compuserve.com', null),
(7566, 'JONES', 'MANAGER', 7839, '1981-04-02', 2975, NULL, 20,'JONES@gmail.com', null),
(7654, 'MARTIN', 'SALESMAN', 7698, '1981-09-28', 1250, 1400, 30,'MARTIN@acme.com', null),
(7698, 'BLAKE', 'MANAGER', 7839, '1981-05-01', 2850, NULL, 30,'BLAKE@hotmail.com', null),
(7782, 'CLARK', 'MANAGER', 7839, '1981-06-09', 2450, NULL, 10,'CLARK@acme.com', '{"skills":["C","C++","SQL"]}'),
(7788, 'SCOTT', 'ANALYST', 7566, '1982-12-09', 3000, NULL, 20,'SCOTT@acme.com', '{"cat":"tiger"}'),
(7839, 'KING', 'PRESIDENT', NULL, '1981-11-17', 5000, NULL, 10,'KING@aol.com', null),
(7844, 'TURNER', 'SALESMAN', 7698, '1981-09-08', 1500, 0, 30,'TURNER@acme.com', null),
(7876, 'ADAMS', 'CLERK', 7788, '1983-01-12', 1100, NULL, 20,'ADAMS@acme.org', null),
(7900, 'JAMES', 'CLERK', 7698, '1981-12-03', 950, NULL, 30,'JAMES@acme.org', null),
(7902, 'FORD', 'ANALYST', 7566, '1981-12-03', 3000, NULL, 20,'FORD@acme.com', '{"skills":["SQL","CQL"]}'),
(7934, 'MILLER', 'CLERK', 7782, '1982-01-23', 1300, NULL, 10,'MILLER@acme.com', null);
这只是有效的。外键只是稳定版本的接受语法（v6.5），但在此预览版本（v6.6）
中确实实现了。测试外键
如果我删除了一个带子行的部门，则提出了一个例外：
mysql> delete from dept where deptno=10;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`emp`, CONSTRAINT `fk_deptno` FOREIGN KEY (`deptno`) REFERENCES `dept` (`deptno`))
mysql>
这是按预期工作的。错误消息清晰。
现在测试并发交易。
在会议1：
mysql> start transaction;
Query OK, 0 rows affected (0.19 sec)
mysql> insert into emp(deptno, ename) values (40, 'Franck');
Query OK, 1 row affected (0.19 sec)
在第2节：
mysql> delete from dept where deptno=40;
这个等待，这是正常的
会议1：
mysql> rollback;
Query OK, 0 rows affected (0.19 sec)
会议2：
mysql> delete from dept where deptno=40;
Query OK, 1 row affected (10.41 sec)
好的，这可以按预期工作。悲观的锁定。
测试可序列化
第一个会话：
mysql> set transaction isolation level serializable;
ERROR 8048 (HY000): The isolation level 'SERIALIZABLE' is not supported. Set tidb_skip_isolation_level_check=1 to skip this error
好，是时候查看文档了。这是我正在运行的版本：
mysql> select version();
+-------------------------------+
| version() |
+-------------------------------+
| 5.7.25-TiDB-v6.6.0-serverless |
+-------------------------------+
1 row in set (0.19 sec)
有一个关于交易和隔离级别的良好文档：https://docs.pingcap.com/tidb/stable/transaction-isolation-levels，它解释了所支持的内容以及它与包括MySQL在内的其他数据库的不同之处。显然，TIDB在隔离级别（例如CockroachdB）上不尝试与MySQL兼容，而不是与PostgreSQL相兼容。这与yugabytedb不同，该b类似于所有隔离级别的postgresql。
如果我对此进行进一步测试，将来可能会添加更多内容。目前，与其他与MySQL兼容的数据库相比，支持与MySQL兼容数据库的外键已经是一件好事。请注意，目前仅在预览版中。
有资格成为分布式SQL 吗？从这个术语的常见用法来看，我想这是因为许多其他分布式SQL数据库的隔离水平有限。只有yugabytedb可以映射到由 sql 标准定义的所有隔离水平。
其他特性
我尝试了CHAT2Query来生成某些SQL功能的测试用例：
-- please show an example for the following features: stored procedure, expression index, partial index
创建过程不起作用。 TIDB不支持存储过程或用户定义的功能。
该文档具有与MySQL的兼容性列表：https://docs.pingcap.com/tidb/stable/mysql-compatibility
yugabytedb中支持所有这些SQL功能（当然具有其后Ql语法和行为）。
可伸缩性
与Yugabytedb的另一个重要区别是，为了进行交易的全局顺序，TIDB分配了由单个“放置驱动程序”生成的时间戳，该时间戳大致相当于Yugabytedb YB-Master。在此时间戳中拥有独特的来源会限制可扩展性，因为所有交易都必须从中获得时间戳。将其视为SQL中的Nocache序列 - 我们不建议这样做。实际上，这意味着TIDB不是为多区域地理分布而设计的。
使用yugabytedb，YB-Master从来都不是SQL交易的临界路径。交易的全球顺序使用：
中解释的混合逻辑时钟（HLC）
Evolving Clock Sync in Distributed Databases | YugabyteDB
探索分布式数据库中各节点的同步时间的不同方法，以及为什么Yugabytedb使用混合逻辑时钟。
yugabyte.com