新增yaf_db模块

[caohao-go]

MySQL数据ORM框架，支持代理方式建立稳定数据库连接池， 使用文档可参考: https://github.com/caohao-php/ycdatabase ， 仅支持 PHP7

[caohao-go]

Catalogue
1.Instruction
2.Requirement
3.Create test table
4.Start yaf_db
5.Init yaf_db connection
6.Native SQL query
7.Error Info
8.Where statement
9.Select statement
10.Insert statement
11.Replace statement
12.Update statement
13.Delete statement
14.Whole Example
15.Database Transaction
16.Data Caching
17.MySQL Database Connection Pool
18.Redis Connection Pool

Instruction
1、Fast : yaf_db is an mysql database ORM written in c, built in php extension, as we known, database ORM is a very time-consuming operation, especially for interpretive languages such as PHP, and for a project, the proportion of ORM is very high,so here I will implement the MySQL ORM operation in C language, and use the performance of C language to improve the performance of ORM.
2、Safe : yaf_db can solve SQL injection through parameter binding.
3、Powerful : concise and powerful usage , support any operation in database.
4、Easy : Extremely easy to learn and use, friendly construction.
5、Data-cache : yaf_db supports data caching. You can use redis as a medium to cache database data, but remember that when the update, insert, and delete operations involve caching data, you need to delete your cache to ensure data consistency.
6、Connection-pool : yaf_db uses a special way to establish a stable connection pool with MySQL. performance can be increased by at least 30%, According to PHP's operating mechanism, long connections can only reside on top of the worker process after establishment, that is, how many work processes are there. How many long connections, for example, we have 10 PHP servers, each launching 1000 PHP-FPM worker processes, they connect to the same MySQL instance, then there will be a maximum of 10,000 long connections on this MySQL instance, the number is completely Out of control! And PHP's connection pool heartbeat mechanism is not perfect

1、快速 - yaf_db是一个为PHP扩展写的纯C语言写的mysql数据库ORM扩展，众所周知，数据库ORM是一个非常耗时的操作，尤其对于解释性语言如PHP，而且对于一个项目来说，ORM大多数情况能占到项目很大的一个比例，所以这里我将MySQL的ORM操作用C语言实现，利用C语言的性能，提升ORM的性能。
2、安全 - yaf_db能通过参数绑定的方式解决SQL注入的问题。
3、强大 - 便捷的函数，支持所有数据库操作。
4、简单 - 使用和学习非常简单，界面友好。
5、数据缓存 - yaf_db支持数据缓存，你可以采用redis作为介质来缓存数据库的数据，但是记得在update、insert、delete 操作涉及到与缓存数据相关的数据修改时，需要按key删除您的缓存，以保证数据一致性。
6、连接池 - yaf_db通过一种特殊的方式来建立一个稳定的与MySQL之间的连接池，性能至少能提升30%，按照 PHP 的运行机制，长连接在建立之后只能寄居在工作进程之上，也就是说有多少个工作进程，就有多少个长连接，打个比方，我们有 10 台 PHP 服务器，每台启动 1000 个 PHP-FPM 工作进程，它们连接同一个 MySQL 实例，那么此 MySQL 实例上最多将存在 10000 个长连接，数量完全失控了！而且PHP的连接池心跳机制不完善。

[caohao-go]

补充了 markdown 文档

[laruence]

能做一些测试用例么， 代码变动有点多， 之前没注意到， 我好好看下。 thanks

[prettykingking]

关于反对合并这个 PR 的主要原因

首先感谢作者对 YAF 所做的贡献。

为什么使用 YAF

PHP 的框架很多，流行常见的，大多数人都用过或了解过。这些框架提供的便捷性使得建立业务原型非常快。
随着业务迅速增长，对各个层面的性能要求提升。我们开始注重性能，逐步提升每个应用组件的响应时间。第一个想到的是，尽可能降低基础框架的 Footprint。这就是 YAF 存在的价值。使得 Footprint 耗时低，占用资源非常小。并且提供了 Request 到 Response 完整的 Workflow。简单、明了、可靠。支持插件，可以基于此根据需要实现更复杂的插件（有的框架称为中间件）。与其它应用（API 调用） 或 IO 类（数据库，缓存）的交互，或可从生态 （Composer，PECL）中安装，或可编写自身简单够用的。应用业务逻辑的资源消耗在任何时候都是自身可控的。用 YAF 的同学应该都有一个共识，就是它所提供的，都是你所必需的，这样应用由小到大。
在 YAF 发布的时候，很多同学习惯性的期待 YAF 也带有数据库 ORM。对于这样的想法，可能 YAF 并不是他们所需要的。YAF 作者也就 ORM 的事情做过简单描述，不提倡使用重量级的 ORM 而放弃简单高效性，这也是 YAF 的初衷。PHP 与 MySQL 天生一对，与生俱来的 PDO 已经对 DB 做了简单抽象。是否使用 ORM 是一种应用取舍，如果加入了 DB Library，那这种取舍不复存在。

什么是 ORM

看完了 README 说明文档，基本上是一系列的工具函数，与 ORM 没有任何关系。参数绑定的语法，既不 MySQL-Native，也不 PHP-Native。ORM 起码要有 对象映射、关系映射。而不仅仅是数据库连接，不仅仅是简单的 CRUD。这里作者对 ORM 有误解。

增加了 YAF 的 Footprint

文档里列出了6个特点。 1-5 没有必要说，因为安全，注入，参数绑定，这些是最基本的。单纯说快速，PHP 连接到 MySQL 性能并没有任何问题。
第 6 点 说到了连接数过多时，影响到性能。属于应用扩展问题，解决方案不一。作者实现了连接池，这里不就实现的连接池展开讨论，不讨论对与错，好与坏。只做一点区分，实现的连接池是解决 MySQL 并发连接数问题，而不是 YAF 框架存在的缺陷。所以这个 DB 扩展并不是必要的，反而增加了 YAF 的 Footprint。况且，并不是每一个使用 YAF 的，一定会使用这个 DB 扩展。

YAF 有需要很多提升的地方，DB Library 绝不会是最优先的，或者根本不需要 。

以上说明，来自一个使用 YAF 的团队客观评论。不带有任何偏见。请 YAF 作者 @laruence 考虑。

[caohao-go]

关于反对合并这个 PR 的主要原因

首先感谢作者对 YAF 所做的贡献。

为什么使用 YAF

PHP 的框架很多，流行常见的，大多数人都用过或了解过。这些框架提供的便捷性使得建立业务原型非常快。
随着业务迅速增长，对各个层面的性能要求提升。我们开始注重性能，逐步提升每个应用组件的响应时间。第一个想到的是，尽可能降低基础框架的 Footprint。这就是 YAF 存在的价值。使得 Footprint 耗时低，占用资源非常小。并且提供了 Request 到 Response 完整的 Workflow。简单、明了、可靠。支持插件，可以基于此根据需要实现更复杂的插件（有的框架称为中间件）。与其它应用（API 调用） 或 IO 类（数据库，缓存）的交互，或可从生态 （Composer，PECL）中安装，或可编写自身简单够用的。应用业务逻辑的资源消耗在任何时候都是自身可控的。用 YAF 的同学应该都有一个共识，就是它所提供的，都是你所必需的，这样应用由小到大。
在 YAF 发布的时候，很多同学习惯性的期待 YAF 也带有数据库 ORM。对于这样的想法，可能 YAF 并不是他们所需要的。YAF 作者也就 ORM 的事情做过简单描述，不提倡使用重量级的 ORM 而放弃简单高效性，这也是 YAF 的初衷。PHP 与 MySQL 天生一对，与生俱来的 PDO 已经对 DB 做了简单抽象。是否使用 ORM 是一种应用取舍，如果加入了 DB Library，那这种取舍不复存在。

什么是 ORM

看完了 README 说明文档，基本上是一系列的工具函数，与 ORM 没有任何关系。参数绑定的语法，既不 MySQL-Native，也不 PHP-Native。ORM 起码要有 对象映射、关系映射。而不仅仅是数据库连接，不仅仅是简单的 CRUD。这里作者对 ORM 有误解。

增加了 YAF 的 Footprint

文档里列出了6个特点。 1-5 没有必要说，因为安全，注入，参数绑定，这些是最基本的。单纯说快速，PHP 连接到 MySQL 性能并没有任何问题。
第 6 点 说到了连接数过多时，影响到性能。属于应用扩展问题，解决方案不一。作者实现了连接池，这里不就实现的连接池展开讨论，不讨论对与错，好与坏。只做一点区分，实现的连接池是解决 MySQL 并发连接数问题，而不是 YAF 框架存在的缺陷。所以这个 DB 扩展并不是必要的，反而增加了 YAF 的 Footprint。况且，并不是每一个使用 YAF 的，一定会使用这个 DB 扩展。

YAF 有需要很多提升的地方，DB Library 绝不会是最优先的，或者根本不需要 。

以上说明，来自一个使用 YAF 的团队客观评论。不带有任何偏见。请 YAF 作者 @laruence 考虑。

我觉得做什么事情是都是为了提升开发效率和性能，你因为YAF简洁，而拒绝接受ORM，然后全方位的去抨击这个东西，本身就是带有很主观性的一个事情，你可以说他不是ORM，但是不可否认，在我的工作中，他比起原生的SQL来说提升的开发效率是非常高的，而且性能方面也肯定比PHP版本的ORM要高不少，而且我认为他不是一个简单的CRUD，即便是简单的 CRUD，我觉得开发过程95%的时间都是写简单的CRUD，复杂的SQL一般都很少去用到 ORM，为什么不去封装下？一定要每个人去写原生的SQL，不知道你有没有认真看整个功能，我上面提供了非常丰富的特性，这花费了我大量精力，你可以说他不适合YAF，但是你去否定这个产品......，另外为什么一定要做对象映射，我这个全部都是以数组的形式输入输出，我觉得反而会更加灵活，如果你需要转化成对象，可以自己封装一层即可。

[prettykingking]

关于反对合并这个 PR 的主要原因

首先感谢作者对 YAF 所做的贡献。

为什么使用 YAF

PHP 的框架很多，流行常见的，大多数人都用过或了解过。这些框架提供的便捷性使得建立业务原型非常快。
随着业务迅速增长，对各个层面的性能要求提升。我们开始注重性能，逐步提升每个应用组件的响应时间。第一个想到的是，尽可能降低基础框架的 Footprint。这就是 YAF 存在的价值。使得 Footprint 耗时低，占用资源非常小。并且提供了 Request 到 Response 完整的 Workflow。简单、明了、可靠。支持插件，可以基于此根据需要实现更复杂的插件（有的框架称为中间件）。与其它应用（API 调用） 或 IO 类（数据库，缓存）的交互，或可从生态 （Composer，PECL）中安装，或可编写自身简单够用的。应用业务逻辑的资源消耗在任何时候都是自身可控的。用 YAF 的同学应该都有一个共识，就是它所提供的，都是你所必需的，这样应用由小到大。
在 YAF 发布的时候，很多同学习惯性的期待 YAF 也带有数据库 ORM。对于这样的想法，可能 YAF 并不是他们所需要的。YAF 作者也就 ORM 的事情做过简单描述，不提倡使用重量级的 ORM 而放弃简单高效性，这也是 YAF 的初衷。PHP 与 MySQL 天生一对，与生俱来的 PDO 已经对 DB 做了简单抽象。是否使用 ORM 是一种应用取舍，如果加入了 DB Library，那这种取舍不复存在。

什么是 ORM

看完了 README 说明文档，基本上是一系列的工具函数，与 ORM 没有任何关系。参数绑定的语法，既不 MySQL-Native，也不 PHP-Native。ORM 起码要有 对象映射、关系映射。而不仅仅是数据库连接，不仅仅是简单的 CRUD。这里作者对 ORM 有误解。

增加了 YAF 的 Footprint

文档里列出了6个特点。 1-5 没有必要说，因为安全，注入，参数绑定，这些是最基本的。单纯说快速，PHP 连接到 MySQL 性能并没有任何问题。
第 6 点 说到了连接数过多时，影响到性能。属于应用扩展问题，解决方案不一。作者实现了连接池，这里不就实现的连接池展开讨论，不讨论对与错，好与坏。只做一点区分，实现的连接池是解决 MySQL 并发连接数问题，而不是 YAF 框架存在的缺陷。所以这个 DB 扩展并不是必要的，反而增加了 YAF 的 Footprint。况且，并不是每一个使用 YAF 的，一定会使用这个 DB 扩展。

YAF 有需要很多提升的地方，DB Library 绝不会是最优先的，或者根本不需要 。

以上说明，来自一个使用 YAF 的团队客观评论。不带有任何偏见。请 YAF 作者 @laruence 考虑。

我觉得做什么事情是都是为了提升开发效率和性能，你因为YAF简洁，而拒绝接受ORM，然后全方位的去抨击这个东西，本身就是带有很主观性的一个事情，你可以说他不是ORM，但是不可否认，在我的工作中，他比起原生的SQL来说提升的开发效率是非常高的，而且性能方面也肯定比PHP版本的ORM要高不少，而且我认为他不是一个简单的CRUD，即便是简单的 CRUD，我觉得开发过程95%的时间都是写简单的CRUD，复杂的SQL一般都很少去用到 ORM，为什么不去封装下？一定要每个人去写原生的SQL，不知道你有没有认真看整个功能，我上面提供了非常丰富的特性，这花费了我大量精力，你可以说他不适合YAF，但是你去否定这个产品......，另外为什么一定要做对象映射，我这个全部都是以数组的形式输入输出，我觉得反而会更加灵活，如果你需要转化成对象，可以自己封装一层即可。

谢谢作者的回复。我想澄清一下，我没有评价这个 DB 扩展本身的好坏，更没有贬低它的意思。主要想表达的是，既然已经是以扩展形式存在，为什么硬要集成到框架中去。让开发者根据需要，选择性的去安装使用它，不是更好吗？

[caohao-go]

关于反对合并这个 PR 的主要原因

首先感谢作者对 YAF 所做的贡献。

为什么使用 YAF

PHP 的框架很多，流行常见的，大多数人都用过或了解过。这些框架提供的便捷性使得建立业务原型非常快。
随着业务迅速增长，对各个层面的性能要求提升。我们开始注重性能，逐步提升每个应用组件的响应时间。第一个想到的是，尽可能降低基础框架的 Footprint。这就是 YAF 存在的价值。使得 Footprint 耗时低，占用资源非常小。并且提供了 Request 到 Response 完整的 Workflow。简单、明了、可靠。支持插件，可以基于此根据需要实现更复杂的插件（有的框架称为中间件）。与其它应用（API 调用） 或 IO 类（数据库，缓存）的交互，或可从生态 （Composer，PECL）中安装，或可编写自身简单够用的。应用业务逻辑的资源消耗在任何时候都是自身可控的。用 YAF 的同学应该都有一个共识，就是它所提供的，都是你所必需的，这样应用由小到大。
在 YAF 发布的时候，很多同学习惯性的期待 YAF 也带有数据库 ORM。对于这样的想法，可能 YAF 并不是他们所需要的。YAF 作者也就 ORM 的事情做过简单描述，不提倡使用重量级的 ORM 而放弃简单高效性，这也是 YAF 的初衷。PHP 与 MySQL 天生一对，与生俱来的 PDO 已经对 DB 做了简单抽象。是否使用 ORM 是一种应用取舍，如果加入了 DB Library，那这种取舍不复存在。

什么是 ORM

看完了 README 说明文档，基本上是一系列的工具函数，与 ORM 没有任何关系。参数绑定的语法，既不 MySQL-Native，也不 PHP-Native。ORM 起码要有 对象映射、关系映射。而不仅仅是数据库连接，不仅仅是简单的 CRUD。这里作者对 ORM 有误解。

增加了 YAF 的 Footprint

文档里列出了6个特点。 1-5 没有必要说，因为安全，注入，参数绑定，这些是最基本的。单纯说快速，PHP 连接到 MySQL 性能并没有任何问题。
第 6 点 说到了连接数过多时，影响到性能。属于应用扩展问题，解决方案不一。作者实现了连接池，这里不就实现的连接池展开讨论，不讨论对与错，好与坏。只做一点区分，实现的连接池是解决 MySQL 并发连接数问题，而不是 YAF 框架存在的缺陷。所以这个 DB 扩展并不是必要的，反而增加了 YAF 的 Footprint。况且，并不是每一个使用 YAF 的，一定会使用这个 DB 扩展。

YAF 有需要很多提升的地方，DB Library 绝不会是最优先的，或者根本不需要 。

以上说明，来自一个使用 YAF 的团队客观评论。不带有任何偏见。请 YAF 作者 @laruence 考虑。

我觉得做什么事情是都是为了提升开发效率和性能，你因为YAF简洁，而拒绝接受ORM，然后全方位的去抨击这个东西，本身就是带有很主观性的一个事情，你可以说他不是ORM，但是不可否认，在我的工作中，他比起原生的SQL来说提升的开发效率是非常高的，而且性能方面也肯定比PHP版本的ORM要高不少，而且我认为他不是一个简单的CRUD，即便是简单的 CRUD，我觉得开发过程95%的时间都是写简单的CRUD，复杂的SQL一般都很少去用到 ORM，为什么不去封装下？一定要每个人去写原生的SQL，不知道你有没有认真看整个功能，我上面提供了非常丰富的特性，这花费了我大量精力，你可以说他不适合YAF，但是你去否定这个产品......，另外为什么一定要做对象映射，我这个全部都是以数组的形式输入输出，我觉得反而会更加灵活，如果你需要转化成对象，可以自己封装一层即可。

谢谢作者的回复。我想澄清一下，我没有评价这个 DB 扩展本身的好坏，更没有贬低它的意思。主要想表达的是，既然已经是以扩展形式存在，为什么硬要集成到框架中去。让开发者根据需要，选择性的去安装使用它，不是更好吗？

既然这样，那我就贴个扩展的地址吧： https://github.com/caohao-php/ycdatabase 谢谢各位。

[prettykingking]

关于反对合并这个 PR 的主要原因

首先感谢作者对 YAF 所做的贡献。

为什么使用 YAF

PHP 的框架很多，流行常见的，大多数人都用过或了解过。这些框架提供的便捷性使得建立业务原型非常快。
随着业务迅速增长，对各个层面的性能要求提升。我们开始注重性能，逐步提升每个应用组件的响应时间。第一个想到的是，尽可能降低基础框架的 Footprint。这就是 YAF 存在的价值。使得 Footprint 耗时低，占用资源非常小。并且提供了 Request 到 Response 完整的 Workflow。简单、明了、可靠。支持插件，可以基于此根据需要实现更复杂的插件（有的框架称为中间件）。与其它应用（API 调用） 或 IO 类（数据库，缓存）的交互，或可从生态 （Composer，PECL）中安装，或可编写自身简单够用的。应用业务逻辑的资源消耗在任何时候都是自身可控的。用 YAF 的同学应该都有一个共识，就是它所提供的，都是你所必需的，这样应用由小到大。
在 YAF 发布的时候，很多同学习惯性的期待 YAF 也带有数据库 ORM。对于这样的想法，可能 YAF 并不是他们所需要的。YAF 作者也就 ORM 的事情做过简单描述，不提倡使用重量级的 ORM 而放弃简单高效性，这也是 YAF 的初衷。PHP 与 MySQL 天生一对，与生俱来的 PDO 已经对 DB 做了简单抽象。是否使用 ORM 是一种应用取舍，如果加入了 DB Library，那这种取舍不复存在。

什么是 ORM

看完了 README 说明文档，基本上是一系列的工具函数，与 ORM 没有任何关系。参数绑定的语法，既不 MySQL-Native，也不 PHP-Native。ORM 起码要有 对象映射、关系映射。而不仅仅是数据库连接，不仅仅是简单的 CRUD。这里作者对 ORM 有误解。

增加了 YAF 的 Footprint

文档里列出了6个特点。 1-5 没有必要说，因为安全，注入，参数绑定，这些是最基本的。单纯说快速，PHP 连接到 MySQL 性能并没有任何问题。
第 6 点 说到了连接数过多时，影响到性能。属于应用扩展问题，解决方案不一。作者实现了连接池，这里不就实现的连接池展开讨论，不讨论对与错，好与坏。只做一点区分，实现的连接池是解决 MySQL 并发连接数问题，而不是 YAF 框架存在的缺陷。所以这个 DB 扩展并不是必要的，反而增加了 YAF 的 Footprint。况且，并不是每一个使用 YAF 的，一定会使用这个 DB 扩展。

YAF 有需要很多提升的地方，DB Library 绝不会是最优先的，或者根本不需要 。

以上说明，来自一个使用 YAF 的团队客观评论。不带有任何偏见。请 YAF 作者 @laruence 考虑。

我觉得做什么事情是都是为了提升开发效率和性能，你因为YAF简洁，而拒绝接受ORM，然后全方位的去抨击这个东西，本身就是带有很主观性的一个事情，你可以说他不是ORM，但是不可否认，在我的工作中，他比起原生的SQL来说提升的开发效率是非常高的，而且性能方面也肯定比PHP版本的ORM要高不少，而且我认为他不是一个简单的CRUD，即便是简单的 CRUD，我觉得开发过程95%的时间都是写简单的CRUD，复杂的SQL一般都很少去用到 ORM，为什么不去封装下？一定要每个人去写原生的SQL，不知道你有没有认真看整个功能，我上面提供了非常丰富的特性，这花费了我大量精力，你可以说他不适合YAF，但是你去否定这个产品......，另外为什么一定要做对象映射，我这个全部都是以数组的形式输入输出，我觉得反而会更加灵活，如果你需要转化成对象，可以自己封装一层即可。

谢谢作者的回复。我想澄清一下，我没有评价这个 DB 扩展本身的好坏，更没有贬低它的意思。主要想表达的是，既然已经是以扩展形式存在，为什么硬要集成到框架中去。让开发者根据需要，选择性的去安装使用它，不是更好吗？

既然这样，那我就贴个扩展的地址吧： https://github.com/caohao-php/ycdatabase 谢谢各位。

最后希望作者不要误会。我尊重你的劳动成果，我们的 PHP 项目也没有使用 ORM。接下来我会建议 PHP 同事去试用这个扩展，研究它所提升的方面。再次谢谢作者。

[phpseven]

方法比较简洁，不过要是可以支持链式写法就更舒适了，😘毕竟堆积的参数有些其实没必要，还容易错位
``
$ycdb->select("user_info_test", "*", [ "username[~]" => "Londo_" ]);

$db->table('xx')->columns(['p.*', "b.xxx"])
->join($join)->where($where)->group('device_id')
->order($order)->limit($limit)->select();

[4352570]

支持增加orm，降低入门门槛，提高易用性，大部分人还是要集成orm

[caohao-go]

Londo_

嗯，你那种方式确实比较好，不过在c语言实现起来会相对有些复杂，所以我这边采用的相对简单一点的方式！

[huagelong]

什么时候能合并？连接池，php真的很需要