> 默认安装时，PostgreSQL 的配置参数通常都偏小，不太适合作为生产服务器使用。所以，安装 PostgreSQL 数据库之后首先需要执行的操作就是对服务器的配置参数进行调整。


![image.png](/static/img/283e572868f9148e7a191eb4664576de.image.webp)




## 查看/设置参数值

我们使用 PostgreSQL 16，服务器的配置参数有 360 多个，运行时的参数值可以使用 SHOW 命令查看：

```
show server_version;

server_version|
--------------|
16.2          |

show all;

name                                       |setting                                            |description                                                                                                                            |
-------------------------------------------+---------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
allow_in_place_tablespaces                 |off                                                |Allows tablespaces directly inside pg_tblspc, for testing.                                                                             |
allow_system_table_mods                    |off                                                |Allows modifications of the structure of system tables.                                                                                |
application_name                           |DBeaver 24.0.2 - SQLEditor <Script-6.sql>          |Sets the application name to be reported in statistics and logs.                                                                       |
...
```

这些参数的详细信息也可以使用 pg_settings 视图进行查看：

```
select name, setting, unit, source, sourcefile, sourceline, short_desc
from pg_settings
where name like '%buffers%';

name          |setting|unit|source            |sourcefile                                         |sourceline|short_desc                                                        |
--------------+-------+----+------------------+---------------------------------------------------+----------+------------------------------------------------------------------+
shared_buffers|16384  |8kB |configuration file|C:/Program Files/PostgreSQL/16/data/postgresql.conf|       130|Sets the number of shared memory buffers used by the server.      |
temp_buffers  |1024   |8kB |default           |                                                   |          |Sets the maximum number of temporary buffers used by each session.|
wal_buffers   |512    |8kB |default           |                                                   |          |Sets the number of disk-page buffers in shared memory for WAL.    |
```

通过 pg_settings 视图不仅可以查看运行时的参数值，而且可以知道这些值的来源。

这些参数有些可以在服务器运行时进行修改，有些需要重启服务器之后才能生效；不同修改方式的优先级不同，下图列出了所有可能的修改方式：

![|1192x939](https://pic2.zhimg.com/80/v2-18bc66cce66db0332e6a9aabf0dc8f21_720w.webp)

以上设置方式的优先级从高到低；也就是说，在一个在事务内部设置的参数值会覆盖其他任何设置，不过该设置只在当前事务中有效。需要注意的是，并非所有参数都可以支持所有的修改方式，具体可以参考官方文档关于 [pg_settings ](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/view-pg-settings.html)的说明。

接下来我们介绍几个重要的配置参数。

## max_connections

[max_connections](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-connection.html%23GUC-MAX-CONNECTIONS) 决定了客户端的最大并发连接数，默认值通常为 100。如果出现连接数过多，无法连接数据库的错误时，可能需要考虑增加最大连接数。不过，修改该参数还需要考虑对其他参数的影响（尤其是 work_mem）；因为它们是基于每个连接设置的值，增加连接数也会导致这些内存使用量的增加。

通常来说，商业服务器至少可以支持几百个连接。如果应用的连接数到大上千或者几千，可以考虑使用连接池技术减少连接的消耗。

修改 max_connections 的方式有两种，修改之后必须重启服务器才能生效：

1. 修改配置文件 postgresql.conf；
2. `alter system set max_connections = N;`，该命令会修改配置文件 postgresql.auto.conf。

对于主从复制中的从节点，必须将该参数的值设置为大于等于主节点上的值；否则，从节点将无法执行查询操作。

## shared_buffers

除了操作系统的 I/O 缓存之外，PostgreSQL 还会使用自己的内部缓存。PostgreSQL 共享内存缓冲区由参数 [shared_buffers](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-resource.html%23GUC-SHARED-BUFFERS) 设置，它决定了 PostgreSQL 能够使用的专用缓存大小。

为确保在所有机器和操作系统上的兼容性，PostgreSQL 默认将该值设置得很小，通常是 128 MB。因此，增加 shared_buffers 的值是提高性能最有效的设置之一。

虽然对于 shared_buffers 没有具体的推荐值，但是可以针对具体的系统计算出一个大概的值。一般来说，对于专用的数据库服务器，shared_buffers 大概可以设置为系统内存的 25%。增加 shared_buffers 的值通常可以提高性能，例如，当整个数据库都可以被加载到缓存中时，可以明显减少磁盘的读取操作。由于 PostgreSQL 还依赖于操作系统的缓存，大于内存 40% 的 shared_buffers 并不会带来性能的提示，反而可能会下降。

虽然增加 shared_buffers 的值可以提高以读为主的系统性能，但是可能影响以写为主的系统性能；因为 shared_buffers 的全部内容必须在写入操作时进行处理。

修改 shared_buffers 的方式有两种，修改之后必须重启服务器才能生效：

1. 修改配置文件 postgresql.conf；
2. `alter system set shared_buffers = 'xxx';`，该命令会修改配置文件 postgresql.auto.conf。

另外，增加 shared_buffers 的值通常也需要相应地增加 max_wal_size 的值，以便延长检查点的时间间隔。

## wal_buffers

PostgreSQL 使用预写日志（WAL）确保数据的持久性；与 shared_buffers 作用类似，PostgreSQL 将 WAL 日志写入缓冲并且批量写入磁盘。

默认的 WAL 缓冲大小由 [wal_buffers](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-wal.html%23GUC-WAL-BUFFERS) 参数进行设置，初始值为 4MB（shared_buffers 的 1/32）。WAL 缓冲区在每次事务提交时都会写入磁盘，因此过大的值并不会带来显着的性能提升。不过，对于大量并发的写入操作，适当增加该参数的值可以提高系统的性能。

修改 wal_buffers 的方式有两种，修改之后必须重启服务器才能生效：

1. 修改配置文件 postgresql.conf；
2. `alter system set wal_buffers = 'xxx';`，该命令会修改配置文件 postgresql.auto.conf。

## effective_cache_size

[effective_cache_size](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-query.html%23GUC-EFFECTIVE-CACHE-SIZE) 参数为 PostgreSQL 提供了一个可供操作系统和数据库使用的缓存估值（考虑了操作系统自身和其他应用之后）。

该参数只是一个评估值，而不是实际的分配值；它仅用于 PostgreSQL 查询计划器判断索引的代价，越大的值越可能使用索引扫描，否则更可能使用表的顺序扫描。

effective_cache_size 默认值为 4 GB，保守估可以设置为是系统可用内存的 1/2。通常对于专用数据库服务器可以设置为系统总内存的 75％，可以根据特定的服务器工作负载进行调整。如果 effective_cache_size 设置过低，查询计划器可能会忽略某些索引，即使通过索引可以明显增加查询的性能。

通过操作系统的统计信息可以得到一个更好的估计值。对于 UNIX/LINUX 系统，将 free 或者 top 命令结果中的 free 加上 cached；对于 Windows 系统，查看任务管理器 Performance 页面中的“System Cache”。

修改 effective_cache_size 不需要重启服务器，通过以下方式修改之后执行`pg_ctl reload`或者`SELECT pg_reload_conf();`重新加载即可：

1. 修改配置文件 postgresql.conf；
2. `alter system set effective_cache_size = 'xxx';`，该命令会修改配置文件 postgresql.auto.conf。

## work_mem

[work_mem](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-resource.html%23GUC-WORK-MEM) 参数用于复杂的排序操作，它决定了中间结果（例如哈希表）或者排序操作可以使用的最大内存。

如果设置了合适的 work_mem 值，大部分的排序操作都在内存中执行，而不需要使用磁盘存储临时结果。对于复杂的查询，可能会执行并发的排序或者哈希操作，每个操作都可以最多使用该参数设置的内存。另外，多个会话可能同时执行排序操作。因此，排序占用的总内存可能是 work_mem 的许多倍；work_mem 的值不能设置的过高，因为它可能导致内存使用瓶颈。

该参数的默认值为 4MB，支持从事务级别到命令行参数的各种修改方式。理想的方式是将全局的 work_mem 参数设置为一个较低的值，然后为具体的查询指定更大的值：

```
SET LOCAL work_mem = '256MB';
SELECT * FROM db ORDER BY LOWER(name);
```

涉及排序操作的 SQL 子句包括 ORDER BY、DISTINCT 以及排序合并连接（Sort Merge Join）。使用哈希表的操作包括哈希连接（Hash Join）、基于哈希的聚合以及基于哈希的 IN 子查询实现。

## maintenance_work_mem

[maintenance_work_mem](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-resource.html%23GUC-MAINTENANCE-WORK-MEM) 参数指定了日常维护操作允许占用的最大内存，例如 VACUUM、CREATE INDEX 以及 ALTER TABLE ADD FOREIGN KEY 等操作。

由于一个数据库会话同时只能执行一个维护操作，一般不会存在并发的维护操作；所以将该参数设置的比 work_mem 大很多也不会有问题，更大的维护内存还能够提高数据库清理和数据导入的性能。

唯一需要注意的是，如果启动了 autovacuum，可能会占用 autovacuum_max_workers（默认为 3）倍 work_mem 设置的内存。我们也可以为此设置单独的 [autovacuum_work_mem](https://link.zhihu.com/?target=https%3A//www.postgresql.org/docs/current/runtime-config-resource.html%23GUC-AUTOVACUUM-WORK-MEM) 参数。

maintenance_work_mem 参数的默认值为 64MB，支持从事务级别到命令行参数的各种修改方式。

## 总结

调整服务器的配置参数通常是我们在安装 PostgreSQL 之后需要进行优化的第一步，本文介绍了如何进行参数的设置以及几个重要参数的作用和调整目标。PostgreSQL 提供了大量可以调整的参数，[PGTune](https://link.zhihu.com/?target=https%3A//pgtune.leopard.in.ua/%23/) 工具给我们提供了一个很好的尝试起点，[wiki.postgresql.org](https://link.zhihu.com/?target=https%3A//wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server) 列出了最常见的几个参数优化；不过性能优化的关键是对工作负载进行基准测试并且和已知的基线进行比较。

另外，数据库的配置优化并不是优化的全部。例如，编写不当的查询语句可能无法通过调整参数解决性能问题；此时我们需要通过其他方式进行优化，比如利用索引或者修改查询的连接方式等。

PostgreSQL性能优化之服务器参数配置

# 01 介绍

<script async src="https://www.googletagmanager.com/gtag/js?id=G-P8BDTJ8V1Q"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-P8BDTJ8V1Q');
</script>
这篇是我学习整理过介绍stable diffusion底层工作原理最简单易懂的，并且我发现使用comfyUI和这个工作原理解读的非常匹配，我相信你一看就能理解。

![image.png](/static/img/d7ec2a689b12728fc270a990ea180629.image.webp)


之所以把这篇放在教程的开头几篇介绍，是为了让大家能更好的入门comfyUI，上一篇也介绍了过了，comfyUI学习门槛更难一点，需要大家对底层原理有一点的了解，这篇的话就是给大家打地基用的，弄懂了原理再去学习工作流，你会发现得心应手，事半功倍，整体提效至少50%。

因为comfyUI是基于workflow工作流的，就是一个个节点配置起来，如果你不懂工作原理，别人分享的工作流你也只仅仅只能使用，想自己微调的话难度就大了。



# 02 原理拆解

这次先从最简单的文生图来拆解分析。
当你输入一个文字，比如 1girl,我们称之为 text prompt，系统会返回给你一张符合你输入文本的描述图片。


![image.png](https://vlogs.iftballs.com/static/img/e3308a7147b37a1e789b05cb4afb3e76.image.webp)

在整个过程中，在底层实现这个工作有三个关键点。
- 1、大模型
- 2、CLIP和VAE
- 3、采样器
- 
下面分别来介绍。

## 2.1 大模型
第一个关键是大模型，模型是拿非常多的图片样本进行计算，这些图片上有大量的文本标记Tag，比如说蒙娜丽莎的图，就会打上达芬奇、写实派、女性、微笑、油画等一系列的属性，我们称之为Tag。

![image.png](https://vlogs.iftballs.com/static/img/9607db2165e65283a60f7157682fc2da.image.webp)

计算的过程中 stable diffusion做了以下三个事情


![image.png](https://vlogs.iftballs.com/static/img/2751c9ecfa9f6bce35ad177964d06634.image.webp)

1：创建了一个叫做潜在空间的地方 Latent space。

2：用算法把这些图片进行压缩，并高度总结图片的特征，图片保留特征并且压缩成了特征的马赛克，这个过程我们称之为加噪音，特征马赛克也称之为噪音。

3：同时stable diffusion对文本的Tag也进行了总结和压缩，这个过程，称之为Token化。所谓的Token化，就是把文字拆解成小的单位，然后形成各种方便计算机可以理解但是人无法理解的字符字母和符号。

用于方便计算机用非常神奇的算法进行各种的匹配，再把图片特征进行总结和压缩，并且把文本tag也进行token化的同时，stable diffusion还依然让图片和Tag保持起对应的关系，但此时就不是图片对应Tag了，而是潜在空间中Latent Space中的特征马赛克和他Token对应的这种关系。

这时候我们就得到了一个懂得非常多的文本和图片的特征的对应关系的大模型。通过大模型可以创建潜在空间latent space。潜在空间里面存放的都是马赛克和文本token的对应关系，这个计算的过程一般称之为训练大模型。

更简单的解释大模型：Stable Diffusion通过大量的图片和文本数据训练，将图片压缩成关键特征的表示，并将文本标签转化为计算机能理解的形式。在这个过程中，它建立了一个内部的、用于存储和处理这些数据的空间（潜在空间）。在这个空间里，图片的特征和文本标签以一种压缩和转化后的形式相互对应，使得模型能够基于文本描述生成或理解图像内容。


![image.png](https://vlogs.iftballs.com/static/img/479d3f4545bea3f99699255593187897.image.webp)

## 2.2 CLIP和VAE
为了让用户输入的内容可以进入latent space进行匹配，就需要工具把人类可以理解的文字和图片进行编码，转换为可以在Latent Space中工作的标识符，这样才能在潜在空间Latent Space中进行匹配，文字Prompt在转换的时候需要用到CLIP编码器把Prompt变成Token，图片会通过VAE编码器转化成特征马赛克（也就是噪音），最后再经过计算，Stable diffusion 会按照我们想要的意图生成一个新的特征马赛克，这个时候我们需要用VAE解码器，把这个特征马赛克转换为图片，这个图片就是我们最终需要的1 girl 的图片了。


![image.png](https://vlogs.iftballs.com/static/img/0ca2abfdc934ef0b84fe49c2a4d91803.image.webp)
## 2.3 采样器
上一步 我们已经把输入的text prompt的 1 girl转化成为了token,同时我们还需要输入一个基础的特征马赛克0，文生图的时候，我们系统就随机生成了一个基础的特征马赛克0，这时候采样器就把Token和基础特征马赛克0通过模型计算出来一个你想要的新的特征马赛克1。

其中Token +基础马赛克0，还有一些其他的内容，我们通称为生成的约束条件 conditioning，这个特征马赛克1会和你输入的token继续计算，这个计算会持续很多次，每次就会越来越趋近于计算机认为你需要的token结果到底是什么样的图形，这个过程叫称之为采样，由于经过多次计算之后，特征马赛克1会越来越趋近于真实的图片，所以称之为Denose（去噪音）。

采样器使用一个算法和一些设置，运行N次计算，最后在Latent Space中得到了一个趋近于你想要的内容的特征马赛克N，这个马赛克N再通过VAE解码器还原成真实的图片，整个文生图的过程就完成了。

在这三个步骤完成之后，我们还需要对生成的图片进行一些后期的处理，在文生图的过程中，最初输入的第一个特征马赛克0一般是一个空的随机图片，图片的尺寸决定了你最后输出的图片的尺寸，这个尺寸一般也就是大模型进行训练时候的尺寸，这个尺寸也很影响你最后生成图片的质量。

**最开始 stable diffusion从1.5之前都是512*512像素的图片，到了stable duffusion XL才变成了1024*1024的尺寸，由于最开始的512*512的尺寸不够大，所以在一般生成的图片之后还要进行后期的工作，比如说放大upscale或者是调色等等，这时候一般不会对图片的内容进行什么样的修改。**

那么从 Text Prompt转化为Token，再加上一个空的随机的图片生成的特征马赛克，把这两个通过采样器跟模型的算法计算出来一个他推测的你需要的特征马赛克N，最后再把特征马赛克换为真实的图片，这就是最最基本的核心流程。

在次基础上会组合出非常多的玩法，比如图生图，就是你在最初输入的第一个特征马赛克0的时候是一个由你输入的图片而计算生成的，比如说controlnet就是在采样器的条件 conditioning中增加了更多的约束。

这个是最简化的模型是为了让初学者可以方便的记忆进行了大量的简化。
## 03 总结

一遍没看懂的，没关系，你只要记住大概的流程，后续结合案例讲解的时候，你回过来看看这里的三部分的原理拆解，你就会有更进一步的理解了。

- 1、大模型
- 2、CLIP和VAE
- 3、采样器

等你理解了stable diffusion的工作原理，后续再组装任何工作流，就会显得游刃有余。

AI学绘画002-ComfyUI超简单工作原理介绍

史上最强的数据库资料集合12种数据库的全方位整理

# mariadb与mysql版本对应关系

![image.png](/static/img/e150b103c0ef7849cfb98ccb2f5ac271.image.webp)




MariaDB 是一个 MySQL 的分支，因此 MariaDB 的版本号和 MySQL 的版本号存在一定的对应关系。下面是 MariaDB 和 MySQL 版本对应关系的一些常见情况：

- MariaDB 10.6 对应 MySQL 8.0
- MariaDB 10.5 对应 MySQL 8.0（有限替代）
- MariaDB 10.4 对应 MySQL 8.0（有限替代）
- MariaDB 10.3 对应 MySQL 5.7
- MariaDB 10.2 对应 MySQL 5.7
- MariaDB 10.1 对应 MySQL 5.6


:::warning{title="注意"}
这只是一个粗略的对应关系，实际上两者之间还存在一些区别。MariaDB 和 MySQL 在某些方面有一些不同的特性和功能，也有不同的优化和扩展。因此，在升级或者迁移时，需要谨慎考虑版本之间的差异，以确保系统的稳定性和兼容性。
:::

我们可以认为Mariadb的10.2，10.3，10.4版本与MySQL 5.7对应；

Mariadb的10.4有限代替MySQL 8；

Mariadb的10.5有限代替MySQL 8；

Mariadb的10.6, 10.7, 10.8, 10.9, 10.10对应MySQL 8。

![image.png](/static/img/74d23ec15d2bb18a798204f61d055510.image.webp)




当前截至到2022年8月8日，Mariadb的版本情况是10.10是Alpha版本，MySQL的主版本是8。

我们可以在：[Mariadb 历史版本](https://mariadb.org/mariadb/all-releases/)[1]查看Mariadb的发布的版本。 

可以在：[Mariadb与MySQL 版本对比](https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/)[2]，查看Mariadb版本与MySQL版本之间对应与功能兼容性的一些介绍，其实就算是Mariadb的10.6和MySQL 8之间也不能算是完全代替，只能算是近似代替，只不过基于二者之间的主要特性而认为可以代替。

详见：[Mariadb的10.6与MySQL 8兼容性介绍](https://mariadb.com/kb/en/incompatibilities-and-feature-differences-between-mariadb-106-and-mysql-80/)[3]，其他版本之间也可以在上述对比页面查询相关的链接。

# 结论
如果你想使用Mariadb是MySQL，如果是选择MySQL 5.7版本，可以使用Mariadb 10.4， 如果是选择MySQL 8，可以选择Mariadb 10.6及其以后的版本，这样更为稳妥。


> 引用链接:

>[1] Mariadb 历史版本: https://mariadb.org/mariadb/all-releases/
>
>[2] Mariadb 与 MySQL 版本对比: https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/
>
>[3] Mariadb的10.6 与 MySQL 8兼容性介绍: https://mariadb.com/kb/en/incompatibilities-and-feature-differences-between-mariadb-106-and-mysql-80/

mariadb与mysql版本对应关系

“京妈，月子里的宝宝，经常在睡觉时咧嘴笑咋回事儿呢？婆婆讲迷信说这是遇上送子婆婆了，被婆婆说的我有点害怕，这种情况用不用去看医生呢？”


![image.png](/static/img/40ad37fd9cc779659bc5c6f626f8bf71.image.webp)

新生宝宝，在睡梦中经常咧嘴微笑，这种情况应该不少新手爸妈都遇到过吧。
哭和笑都是常见的表情，但刚出生不久的宝宝，清醒的时候只会哭，并不会微笑，只有在睡着后有时能看到宝宝微笑，这到底是怎么回事儿呢？

接下来，就跟着京妈一起来探究新生小婴儿的“微笑秘密”吧！






为什么新生儿宝宝睡着时经常咧嘴微笑？不一定是做梦
我儿子在月子里经常在睡梦中微笑，我妈看着他笑，自己也偷偷的微笑，还跟我说“你看他经常做梦在笑，多聪明” ！
其实呀，新生宝宝经常在睡着后咧嘴微笑，主要是和这个阶段的生长发育情况有关系。
由于中枢神经发育还不完善，睡觉时大脑皮层处于弥散性抑制状态，对身体各部位的肌肉群控制能力有限，那宝贝在睡眠过程中就可能出现一过性的口周肌肉不自主运动，看上去好像在“微笑”。




另外，新生宝宝出生后要快速发育，每天大部分时间都在睡觉，出生第一个月的宝宝每天大约能睡16-20小时。
但睡眠周期又不同于成人，一个深浅睡眠的周期大约是50分钟左右。
当处于深睡眠状态时，宝宝看上去很安静，但当处于浅睡眠状态时，睡得相对不踏实，可能出现眼球活动、眼睑活动、呼吸不规律、吸吮和咀嚼等动作。
不过，这都是正常现象，妈妈不用担心，宝宝在睡眠中微笑，说明精神比较放松，内心感到满足和愉悦。
看到这种现象，妈妈不要打扰宝宝，要保持安静的睡眠环境，温度和湿度也适宜，这样可以让宝宝睡得更好，也更利于成长和发育。




宝宝什么时候才会自主的笑？越早笑越聪明
当爸爸妈妈看到宝宝第一个发自内心的笑容时，会特别高兴，之前那些无眠之夜和让人崩溃混乱的日子都突然变得无关紧要了。
那么，宝宝多大就会自主的笑了呢？
一般来说，宝宝从无意识到自主笑，会经历3个阶段：
① 0-1个月：反射性微笑。
这个阶段的宝宝，有时妈妈会在他吃饱、睡着后，看到宝贝露出微笑，不过这时的微笑，是自发性的、无意识的，并不会和妈妈有眼神的交流。




② 1-2个月：有意识地微笑。
随着宝宝情感和社交能力的发展，一般到了4-6周，在被外界刺激时就可能出现有意识地微笑。但不同的宝宝有个体差异，出现有意识微笑早的宝宝，相对来说比较聪明。
这时妈妈要多和宝宝互动，让他与你的笑容互动。
《美国儿科学会育儿百科》指出：这种互动越多，宝宝的大脑发育程度就越高，他的注意力就越容易从本能上转移开，对他的整体发育至关重要。




③ 3-4个月：社会性微笑。
到了3个月，宝宝将成为“笑容交流大师”，他们已经能认出妈妈了。
这个阶段的宝宝，有时会用一个灿烂的笑容、咯咯的笑声来吸引妈妈的注意力，主动开始和妈妈“聊天”。
有时就躺着看着妈妈，知道你露出笑容，他会做出热烈的回应，甚至手舞足蹈的整个身体都参与进来。
笑和哭一样，是宝宝表达需求的一种方式，随着有意识地笑，会让宝宝对周围发生的一切更有控制感，而且学会和大人互动，享受其中的乐趣。
美国专家伊林沃夫曾做过跟踪，研究发现如果宝宝在出生3天后就会笑，到6岁时智商可高达180，因此他认为：宝宝越早逗笑，就越聪明。
其实生活中我们也发现了，爱笑的宝宝更容易获得关注、被周围人喜欢。而宝宝为了增加被关注、被喜欢，会笑容增多，也间接的说明这是宝宝聪明的表现。
看完这些是不是觉得人类幼崽很有趣、很可爱呢？




初为人父母，小宝宝出生后的科学养育很重要，只有家长做得对，才可以帮助宝宝发育的更健康、更聪明！
你家宝宝喜欢笑吗？是从多大开始会自主微笑的呢？欢迎来和新手家长们分享你的带娃经验呀！

01 介绍

💨🏹🌀 2024年，史上最强的数据库资料集合

mariadb与mysql版本对应关系