如果您想要删除 Linux 系统中的完整命令历史记录，包括以前的所有命令记录，可以尝试以下方法来清除历史记录：
删除历史记录文件：
Linux 系统通常将用户的命令历史记录保存在一个文件中，您可以删除或清空这个历史记录文件来清除所有记录。历史记录文件通常是用户的家目录下的 .bash_history 文件。
rm ~/.bash_history清空当前会话和写入历史记录文件：
您可以通过 history -c 命令清空当前会话的历史记录，然后使用 history -w 强制将当前会话的历史记录写入历史记录文件中。
history -c
history -w修改历史记录保存位置：
如果您希望将历史记录保存到其他位置，可以通过设置 HISTFILE 变量来指定历史记录文件的路径。例如，将历史记录保存到 /dev/null 中，表示不保存历史记录。
export HISTFILE=/dev/null请注意，在执行这些操作之前，请务必确认您真的要删除历史记录，因为这些操作是不可逆的。删除历史记录后，以前输入的命令将无法再通过历史记录查看或检索。
观察客户端 每2分钟 websocket 断开连接, 提示 1006 CLOSE_ABNORMAL.
服务端观察日志能发现的确与客户端同一时间断开连接. 但服务端onClose事件并不是服务端主动要求断开的.
客户端也有6秒 定时发ping包, 双方心跳检测都不是超时问题.
知道运维同学 帮忙查了下, 使用cloudflare CDN的新域名观察后并没有这个问题.
那就破案了,现有的域名CND用的都是Google Cloud , 运维同学咨询了谷歌售后服务. 回答的都绝了
聊天内容如下 :
> $1 : 关于负载均衡的问题，,用户 -> 负载均衡 -> nginx，https的服务没有问题，websocket的服务2分钟后就断了
> $1 : timeout设置为999999999
> $2 : 这是有哪些地方需要单独设置吗> $1 : 对
> $2 : 那会影响https的服务吗
> $1 : 对
> $2 : 把websocket单独令出来上面对话简单来说就是 我们webscoket服务用的谷歌云的负载均衡,又一个超时配置. 120秒没有请求过来负载机切换到其他服务器了. 就算后面是单机他也会断开. 调整这个问题很简单,单独配置websocket的负载. 调大超时秒数.
谷歌云的负载均衡超时仅依赖于短链接请求. 并不适用于长连接, 只能通过加超长的timeout 解决问题
WebSocket断开时，会触发CloseEvent, CloseEvent会在连接关闭时发送给使用 WebSockets 的客户端. 它在 WebSocket 对象的 onclose 事件监听器中使用。CloseEvent的code字段表示了WebSocket断开的原因。可以从该字段中分析断开的原因。
CloseEvent有三个字段需要注意, 通过分析这三个字段，一般就可以找到断开原因
CloseEvent.code: code是错误码，是整数类型CloseEvent.reason: reason是断开原因，是字符串CloseEvent.wasClean: wasClean表示是否正常断开，是布尔值。一般异常断开时，该值为false
一般来说1006的错误码出现的情况比较常见，该错误码一般出现在断网时。
|状态码| 名称| 描述|
|-|-|-|
|0–999| |保留段, 未使用.|
|1000| CLOSE_NORMAL| 正常关闭; 无论为何目的而创建, 该链接都已成功完成任务.|
|1001| CLOSE_GOING_AWAY| 终端离开, 可能因为服务端错误, 也可能因为浏览器正从打开连接的页面跳转离开.|
|1002| CLOSE_PROTOCOL_ERROR| 由于协议错误而中断连接.|
|1003| CLOSE_UNSUPPORTED| 由于接收到不允许的数据类型而断开连接 (如仅接收文本数据的终端接收到了二进制数据).|
|1004| | 保留. 其意义可能会在未来定义.|
|1005 |CLOSE_NO_STATUS| 保留. 表示没有收到预期的状态码.|
|1006 |CLOSE_ABNORMAL| 保留. 用于期望收到状态码时连接非正常关闭 (也就是说, 没有发送关闭帧).|
|1007 |Unsupported Data| 由于收到了格式不符的数据而断开连接 (如文本消息中包含了非 UTF-8 数据).|
|1008 |Policy Violation| 由于收到不符合约定的数据而断开连接. 这是一个通用状态码, 用于不适合使用 1003 和 1009 状态码的场景.|
|1009 |CLOSE_TOO_LARGE| 由于收到过大的数据帧而断开连接.|
|1010 |Missing Extension| 客户端期望服务器商定一个或多个拓展, 但服务器没有处理, 因此客户端断开连接.|
|1011 |Internal Error| 客户端由于遇到没有预料的情况阻止其完成请求, 因此服务端断开连接.|
|1012 |Service Restart| 服务器由于重启而断开连接.|
|1013 |Try Again Later| 服务器由于临时原因断开连接, 如服务器过载因此断开一部分客户端连接.|
|1014 ||由 WebSocket标准保留以便未来使用.|
|1015 |TLS Handshake |保留. 表示连接由于无法完成 TLS 握手而关闭 (例如无法验证服务器证书).|
|1016–1999 ||由 WebSocket标准保留以便未来使用.|
|2000–2999 ||由 WebSocket拓展保留使用.|
|3000–3999 ||可以由库或框架使用.? 不应由应用使用. 可以在 IANA 注册, 先到先得.|
|4000–4999 ||可以由应用使用.|
MySQL是一种流行的关系型数据库管理系统，从MySQL 5.7版本开始，引入了对JSON数据类型的支持。json_extract函数是MySQL提供的用于操作和提取JSON字段数据的函数之一。本文将介绍json_extract函数的用法和示例，并探讨其在处理JSON字段中的应用。
json_extract函数用于从JSON字段中提取特定的数据。它的语法如下：
json_extract(json_doc, path[, path]...)其中，json_doc是要提取数据的JSON字段，path是一个或多个用于指定所需数据位置的JSON路径表达式。
下面是一些json_extract函数的使用示例：
假设有一个名为data的JSON字段，其值为{"name": "John", "age": 25, "city": "New York"}。要提取name属性的值，可以使用以下语句：
SELECT json_extract(data, '$.name') AS name FROM table_name;这将返回一个名为name的列，其中包含John作为每一行的值。
如果JSON字段中包含嵌套结构，可以使用json_extract函数提取嵌套属性的值。假设有一个名为data的JSON字段，其值为{"name": "John", "address": {"city": "New York", "country": "USA"}}。要提取address属性中的city值，可以使用以下语句：
SELECT json_extract(data, '$.address.city') AS city FROM table_name;这将返回一个名为city的列，其中包含New York作为每一行的值。
如果JSON字段中包含数组，可以使用json_extract函数提取数组中的值。假设有一个名为data的JSON字段，其值为{"names": ["John", "Jane", "Alice"]}。要提取names数组中的第一个元素，可以使用以下语句：
SELECT json_extract(data, '$.names[0]') AS first_name FROM table_name;这将返回一个名为first_name的列，其中包含John作为每一行的值。
json_extract函数是MySQL中用于处理JSON字段的强大工具之一。通过使用JSON路径表达式，可以方便地从JSON字段中提取所需的数据。本文介绍了json_extract函数的基本用法和示例，包括提取单个值、嵌套值和数组值。
希望本文对您理解MySQL中json_extract函数的用法有所帮助，并能在处理JSON字段时提供指导。
请注意，上述博客是Markdown格式，您可以将其保存为.md文件，并使用适当的Markdown编辑器进行编辑和格式化。同时，请根据您的实际情况和风格要求进行必要的调整和修改。
引用文献：
请注意，这是MySQL 5.7版本的官方文档，其中包含有关JSON函数的详细信息和示例。您可以在该文档中深入了解json_extract函数及其他相关函数的使用方法和功能。
记录一下 今天遇到个问题. 查了查网上的说法 .
先描述问题
CREATE TABLE `table` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`uid` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'UID',
`type` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '1 2',
`t_time` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'UID',
`create_time` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '毫秒时间戳',
PRIMARY KEY (`id`),
KEY `idx_utc` (`uid`,`type`,`create_time`),
KEY `idx_time` (`t_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ;-- 唯一索引
SELECT * FROM `table` WHERE `uid` = 1 and `type`=1 and create_time > 1676009369000 ORDER BY `id` DESC LIMIT 0, 50;
-- 普通索引
SELECT * FROM `table` WHERE `uid` = 1 and `type`=1 and create_time > 1676009369000 ORDER BY `id` DESC LIMIT 0, 50;上面的SQL 可以看到 idx_utc 索引字段都已经使用了. 但order by 使用了主键索引与唯一索引字段. 两条SQL 都没使用到 idx_utc .
查了一圈, 很多文章都是在说 order by 对主键索引排序会用到索引，其他的索引失效
如果有这么一条sql：
select * from table where a=1 and b>10 order by c;如果想在abc三列上去建立一个复合索引，那么如何建立？？？
在acb列上建立索引? ? ?
不推荐这样建立索引，这样的情况相当于在ac列上建立索引！！！
实际上推荐的是在ab上建立索引。
mysql语句的各个子句中。where子句是筛选数据，order by子句是排序数据。order by排序where子句筛选后的数据集，若where子句使用的是索引访问类型（explain的type列）为index或以上的类型，那么数据集是以索引的顺序的有序集合。若order by筛选的顺序正好是索引的顺序，那么才能优化索引。
但where语句和order by语句处理数据时机不同。order by的索引最左前缀和where子句最左前缀不能相互影响。即acb复合索引中：where走ab索引，order去走c索引的情况是不存在的。
即若建立acb索引，那么where会使用a索引进行筛选，因为where不存在c列条件，那么不能使用b列进行筛选，该索引等效于ac列。
where语句和order by语句处理数据时机不同。order by的索引最左前缀和where子句最左前缀不能相互影响。即acb复合索引中：where走ab索引，order去走c索引的情况是不存在的。
看考资料 :
一文搞懂MySQL索引（清晰明了）
MySql性能（7）—MySql对order by排序优化
将原始域名透传
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;