当需要查询 MySQL 数据库表的内存大小时，可以使用以下步骤：

查询 MySQL 数据库表内存大小

1. 登录到 MySQL 数据库：

mysql -u username -p

2. 选择要查询的数据库：

USE database_name;

3. 运行以下查询语句，以获取表的内存大小：

SELECT table_name AS "Table",
       round(((data_length + index_length) / 1024 / 1024), 2) AS "Size (MB)"
FROM information_schema.tables
WHERE table_schema = 'database_name'
      AND table_name = 'table_name';

确保将 database_name 替换为实际的数据库名称，table_name 替换为要查询的表名。

这个查询语句将返回指定表的内存大小（数据长度 + 索引长度），以 MB 为单位。

结论

通过以上步骤，您可以查询 MySQL 数据库表的内存大小。这对于了解表的大小以及优化数据库性能非常有用。

请注意，查询结果可能会略有偏差，因为它仅提供了近似的数据大小。此外，查询过程可能需要一些时间，具体取决于数据库的大小和性能。

记录一下今天踩的坑.

同事构建了一个服务后到开发环境, 之后整台服务器就一直抛错, CPU狂飙, 16核的机器负载上到 七八百.
发现问题后, 第一时间将开发环境 superver 服务 stop all.
全部停止后发现 让然存在很多子进程未杀死

 ps -ef |grep -i swoole |awk '{print $2}' |xargs  kill -9

全部swoole 进程杀死后,等待1分钟 , top 检测负载降了下来. 重启服务.

supervisorctl start all

重启后查看 supervisorctl status , 一直存在部分服务重启失败.

嘿嘿, 抛错 fork: retry: No child processes

查看 ulimit -a , max user processes (-u) 4096

很明显 dev1 开发账户控制的进程数超出上限了.

ulimit -u 10000

果然, 执行指令 就ok了, 不在抛错了.

跑批量任务需要分批按顺序把主键取出来，语句如下：

SELECT id FROM foo.bar LIMIT 10 OFFSET 0
+-----+
| id  |
+-----+
| 109 |
| 13  |
| 14  |
| 15  |
| 128 |
| 129 |
| 130 |
| 190 |
| 226 |
| 227 |
+-----+

发现虽然用主键去查，但结果没有按照主键排序。

查询*试试

SELECT * FROM foo.bar LIMIT 10 OFFSET 0
+----+-------+---+
| id | a     | b |
+----+-------+---+
| 1  | 24274 | 0 |
| 2  | 24274 | 0 |
| 3  | 24274 | 0 |
| 4  | 24274 | 0 |
| 5  | 24274 | 0 |
| 6  | 24274 | 0 |
| 7  | 24274 | 0 |
| 8  | 24274 | 0 |
| 9  | 24274 | 0 |
| 10 | 24274 | 0 |
+----+-------+---+

排序按照主键。
查看执行计划，结果如下：

EXPLAIN SELECT * FROM foo.bar LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id            | 1
select_type   | SIMPLE
table         | bar
partitions    | <null>
type          | ALL
possible_keys | <null>
key           | <null>
key_len       | <null>
ref           | <null>
rows          | 211
filtered      | 100.0
Extra         | <null>

发现select * 没走索引，使用了全表扫描，因此顺序为主键顺序。

EXPLAIN SELECT id FROM foo.bar LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id            | 1
select_type   | SIMPLE
table         | bar
partitions    | <null>
type          | index
possible_keys | <null>
key           | idx_a
key_len       | 8
ref           | <null>
rows          | 211
filtered      | 100.0
Extra         | Using index

而select id并没有用到聚簇索引。innodb二级索引会自动添加主键作为索引列最后一项，使用该索引也能做到覆盖查询。查询优化器使用该索引，导致返回的顺序不符合预期。

SELECT a,id FROM foo.bar LIMIT 10 OFFSET 0
+------+-----+
| a    | id  |
+------+-----+
| 1004 | 109 |
| 1823 | 13  |
| 1823 | 14  |
| 1823 | 15  |
| 1823 | 128 |
| 1823 | 129 |
| 1823 | 130 |
| 1823 | 190 |
| 1823 | 226 |
| 1823 | 227 |
+------+-----+

发现果然之前select id用的是a的索引，并且是按照a,id的顺序排序。
强制使用主键索引试一下

SELECT id FROM foo.bar FORCE INDEX(PRI) LIMIT 10 OFFSET 0
+----+
| id |
+----+
| 1  |
| 2  |
| 3  |
| 4  |
| 5  |
| 6  |
| 7  |
| 8  |
| 9  |
| 10 |
+----+

强制使用主键索引，果然没问题了。
或者使用order by id引导查询优化器使用主键索引也可以：

explain SELECT id FROM boss_business.boss_block_refund_order order by id LIMIT 10 OFFSET 0 \G
***************************[ 1. row ]***************************
id            | 1
select_type   | SIMPLE
table         | boss_block_refund_order
partitions    | <null>
type          | index
possible_keys | <null>
key           | PRIMARY
key_len       | 8
ref           | <null>
rows          | 10
filtered      | 100.0
Extra         | Using index

另外需要注意，MyISAM引擎表在没有任何的删除、修改操作下，执行select 不带order by，那么会按照插入顺序进行排序。因为使用MyISAM存储引擎的表会把索引信息另外存储到一个称为索引文件的另一个文件中。总之Mysql的查询优化器一定会倾向于使用最优的方式。

参考链接
MySQL 默认排序真的是按主键来排序的吗
mysql默认的排序方式

原文地址 : https://juejin.cn/post/6844903861086322702

mysql 的视图不是一种物化视图，它相当于一个虚拟表，本身并不存储数据，当sql在操作视图时所有数据都是从其他表中查出来的。

这带来的问题是使用视图并不能将常用数据分离出来，优化查询速度。

且操作视图的很多命令都与普通表一样，这会导致在业务代码中无法通过sql区分表和视图，使代码变得复杂。

实现视图的方式有两种，分别为合并算法和临时表算法，合并算法是指查询视图时将视图定义的sql合并到查询sql中，比如:

create view v1 as select * from user where sex=m;

当我们要查询视图时，mysql会将 :
select id,name from v1; 合并成 select id,name from user where sex=m……;

临时表算法是先将视图查出来的数据保存到一个临时表中，查询的时候查这个临时表。

不管是合并算法和临时表算法都会带来额外的开销, 且如果使用临时表后会使mysql的优化变得很困难，比如索引。而且视图还引入了一些其他的问题，使得其背后的逻辑非常复杂。

当然，视图在某些情况下可以帮助提升性能，但视图的性能很难预测。且在mysql的优化器中，视图的代码执行路径也完全不同，无法直观的预测其执行性能。

使用facebook- PHP-Webdriver自动化测试 ( 步骤请以github上wiki或者packagist文档上为准 )

a、安装chrome和chrome-driver

b、安装java 并下载selenium的java server -- selenium-server-standalone-3.141.59（独立服务器），访问localhost:4444/wd/hub有响应标识成功

java -jar selenium-server-standalone-2.39.0.jar

c、下载扩展包 - 运行php脚本

{
    "require": {
        "facebook/webdriver": "^1.6.0"
    }
}

d、获取cookie用户登录凭证

<?php
// 初始化
require_once('./vendor/autoload.php');

use Facebook\WebDriver\Remote\RemoteWebDriver;
use Facebook\WebDriver\Remote\DesiredCapabilities;
use Facebook\WebDriver\WebDriverBy;
use Facebook\WebDriver\WebDriverOptions;

// Selemium服务器
$host = 'http://localhost:4444/wd/hub'; // this is the default
$driver = RemoteWebDriver::create($host, DesiredCapabilities::chrome());

// 登录地址
$driver->get("http://127.0.0.1/index.php");
// 进入iframe
$driver->switchTo()->frame('aa');
// 进入登录表单iframe
$driver->switchTo()->frame('userLoginWindow_frame');
// 用户名
$driver->findElement(WebDriverBy::id("ext-comp-1005"))->sendKeys("root");
// 密码
$driver->findElement(WebDriverBy::id("ext-comp-1008"))->sendKeys("123456");
// 点击登录
$driver->findElement(WebDriverBy::id('ext-gen9'))->click();
// 获取cookie
$cookie = $driver->manage()->getCookies();
print_r($cookie);

各个下载地址：

chrome-driver：

https://sites.google.com/a/chromium.org/chromedriver/

selenium-server：

https://www.seleniumhq.org/download/

windows - java：

https://www.java.com/zh_TW/download/help/windows_manual_download.xml

composer - php-web-driver：

http://packagist.p2hp.com/packages/facebook/webdriver