sc create gitea start= auto binPath= "\"C:\Users\DELL\Desktop\hurong\services\gitea\gitea-1.22.6-gogit-windows-4.0-amd64.exe\" web --config \"C:\Users\DELL\Desktop\hurong\services\gitea\custom\conf\app.ini\""

进入services.msc, 查看gitea服务是否已启动

nginx反向代理

配置host域名 127.0.0.1 gitea.choshui
由于我的gitea运行在宿主机, 而nginx是运行在容器中
因此需要反向代理宿主机服务端口, 配置如下

server {
    listen 80;
    server_name gitea.choshui;
    location / {
        # 反向代理宿主机服务端口
        proxy_pass http://host.docker.internal:3000;
    }
}

2024-12-25

Mysql之1118RowSizeTooLarge

场景

有一天尝试往开发环境某张表添加字段, 结果报mysql错误如下:

1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126.
This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

该错误提示我们，行大小超过了InnoDB存储引擎所能支持的最大行大小。

对于InnoDB表，未计算BLOB类型字段的情况下，最大行大小是8126字节。

原因分析

此问题的根本原因在于单行数据的总大小（包括所有列的数据和一些内部开销）超出了InnoDB存储引擎所允许的最大值。

具体原因可能有以下几种：

字段过多或过大：如果一个表中包含大量的VARCHAR、CHAR等固定长度类型的字段，或者这些字段定义了过大的最大长度，可能会导致行大小超过限制。
字符集的影响：某些多字节字符集（如utf8mb4），每个字符占用的空间比单字节字符集（如latin1）要大，这也会增加行的总大小。
Row Format设置不当：InnoDB表默认使用Compact行格式，它对行的存储做了优化，但如果行内数据特别大，可能会触发这个错误。此时可以考虑将行格式更改为Dynamic或Compressed来解决问题。
MySQL的严格模式（Strict Mode）会影响数据插入的行为，例如不允许插入超出字段长度限制的数据。如果你遇到的是由于严格模式导致的问题，可以通过以下方式查看和临时关闭它

解决方案

针对上述原因，我们可以采取如下措施来解决“Row size too large”的问题：

调整字段类型：将较大的VARCHAR字段转换为TEXT或MEDIUMTEXT等类型，特别是当字段内容确实需要存储大量文本时。这样做不仅解决了行大小的问题，还提高了查询性能，因为TEXT/BLOB类型的字段不会影响行头信息的大小。
减少不必要的字段：检查并移除那些不必要或很少使用的字段，以减小每行记录的平均大小。
更改字符集：如果适用的话，可以考虑使用占用空间较小的字符集，比如从utf8mb4转到utf8，但需注意这样做可能会丢失对某些特殊字符的支持。
修改表的ROW_FORMAT：通过ALTER TABLE table_name ROW_FORMAT=DYNAMIC;命令，将表的行格式改为DYNAMIC或COMPRESSED。这样可以让InnoDB更好地处理较大的行，尤其是含有长字符串或BLOB字段的情况。
分拆表结构：如果以上方法都不能解决问题，那么可以考虑将一张大表拆分成多个表，从而降低单行的大小。

检查是否开启严格模式

1 2	show variables like '%innodb_strict_mode%' --临时关闭严格模式,执行相关DDL语句

数据表之碎片优化

有时，即使没有进行明显的改动，随着数据的增删改操作，表也可能出现碎片化现象，进而间接导致行大小问题。

启用innodb_file_per_table参数可以确保每个InnoDB表都有自己独立的.ibd文件，有利于管理表空间和减少碎片。可以通过以下命令检查当前设置：

1	SHOW VARIABLES LIKE 'innodb_file_per_table';

2024-12-25

Mysql之binlog

MySQL 的二进制日志（binlog）是数据库管理员和开发者的重要工具，用于记录所有对数据库的更改操作。
通过 binlog，可以实现数据恢复、故障排查、审计跟踪以及主从复制等功能。
本文将汇总使用 MySQL binlog 的经验和技巧，帮助读者更好地理解和利用这一强大功能。

场景

某天我正在开发, 正在调试中的用户就被莫名的删除了
因此我在想, 遇到类似这样的场景, 该如何恢复数据呢?

1. 理解 MySQL Binlog Binlog 文件内容：

事务开始/结束：每个事务以 BEGIN 和 COMMIT 或 ROLLBACK 标记。
表映射 (Table Map Event)：定义了即将进行的操作将作用于哪个表。
行事件 (Row Events)：如 Write_rows、Update_rows 和 Delete_rows，它们记录了具体行的变化。
Binlog 格式：

STATEMENT：记录完整的 SQL 语句。
ROW：记录每行的变化，适用于高并发环境下的精确恢复。
MIXED：根据情况自动选择 STATEMENT 或 ROW 模式。

2. 查看和解析 Binlog 使用 mysqlbinlog 工具：

1	mysqlbinlog --no-defaults --base64-output=DECODE-ROWS --verbose /path/to/binlog.000127

–base64-output=DECODE-ROWS：解码行事件中的 base64 编码数据。
–verbose：增加输出详细程度，显示更多关于每个事件的信息。
结合时间范围：

1	mysqlbinlog --no-defaults --base64-output=DECODE-ROWS --verbose --start-datetime="2024-12-25 16:00:00" --stop-datetime="2024-12-25 17:00:00" /path/to/binlog.000127

过滤特定操作：
为了筛选特定类型的 SQL 语句或操作，可以结合 grep 使用：

1	mysqlbinlog --no-defaults --start-datetime="2024-12-25 16:00:00" --stop-datetime="2024-12-25 17:00:00" /path/to/binlog.000127 \| grep -i 'delete'

3. 数据恢复点-in-time 恢复：

恢复最新的备份。
确定恢复的时间点。

应用 binlog 文件：

1	mysqlbinlog --start-datetime="2024-12-25 16:00:00" --stop-datetime="2024-12-25 16:33:13" /path/to/binlog.000127 \| mysql -u [user] -p[password] -h [host]

编辑并重放 binlog：

如果需要移除某些删除或更新操作，可以先提取 binlog 内容到文件中，手动编辑后重放：

1
2
3

mysqlbinlog --start-datetime="2024-12-25 16:00:00" --stop-datetime="2024-12-25 17:00:00" /path/to/binlog.000127 > edited_binlog.sql
# 编辑 edited_binlog.sql 文件，移除所有 DELETE 和 DROP 操作
mysql -u [user] -p[password] -h [host] < edited_binlog.sql

4. 处理 Base64 编码的数据

当 binlog 格式设置为 ROW 时，MySQL 会以 base64 编码格式记录行变化。要读取这些编码数据：

正确使用 mysqlbinlog 解析：

1	mysqlbinlog --no-defaults --base64-output=DECODE-ROWS --verbose /path/to/binlog.000127

编程语言解析：使用 Python 结合 mysql-connector-python 或其他库来解析 binlog 文件。

5. 实用技巧与注意事项

权限管理：确保有足够的权限来读取 binlog 文件和执行相关命令。
备份当前状态：在任何恢复操作之前，先对当前数据库进行备份。
测试环境：尽可能在非生产环境中模拟整个过程，避免意外的数据丢失或其他问题。
使用专用工具：对于复杂的 binlog 分析任务，考虑使用 Percona Toolkit 或其他第三方工具。

结论

MySQL binlog 是一个强大的工具，能够帮助我们进行多种管理和维护工作。掌握如何查看、解析和恢复 binlog 中的数据，不仅提高了我们的数据库管理技能，也为应对突发情况提供了有效的手段。希望本文的经验总结能为你提供有价值的参考，助力你在数据库管理的道路上更加得心应手。

参考资料

MySQL 官方文档
Percona Toolkit 文档

2024-12-25

nginx踩坑之alias

场景

在配置 Nginx 服务器以服务静态文件时，

我们通常会使用 root 或 alias 指令来指定这些文件所在的目录。

然而，在实践中，alias 的行为可能会与预期不符，导致返回404错误或其他意外情况。

例如，考虑这样一个需求：您希望所有发送到 /static/ 路径的请求都映射到服务器上的 /var/www/staticfiles/ 目录。

如果配置不当，即使该路径下的文件确实存在，Nginx 也可能无法正确地找到并提供它们。

分析

alias 和 root 指令虽然看似相似，但它们的行为是不同的。

root 指令会将 URI 附加到指定的路径之后，而 alias 则会直接替换 URI。

因此，当使用 alias 指令时，必须确保准确地指定路径，而不包括 URI 的一部分。

一个常见的误区是在 alias 后面添加了多余的斜杠，这会导致路径解析错误。

此外，alias 应该用于 location 块中，而不是 server 块中。

如果您在 server 上级定义了一个 alias，则它不会按照预期工作，因为 alias 是为特定 location 定义的。

解决问题

server {
    listen 80;
    server_name yourdomain.com;

    location /static/ {
        alias /var/www/staticfiles/;
        # 注意这里没有额外的斜杠！
        # 错误示例: alias /var/www/staticfiles/;
    }
}

同时，确保您的 Nginx 版本是最新的，因为旧版本可能存在一些 bug，影响 alias 的行为。

另外，请检查文件权限和 SELinux 设置（如果适用），以确保 Nginx 进程有权限读取静态文件。

最后，测试配置的有效性非常重要。可以通过命令 nginx -t 来验证配置语法是否正确，

并通过实际访问站点来确认一切工作正常。

2024-12-25

php-iconv

public static function export_csv($filename,$data) {
    ob_end_clean();
    //setlocale(LC_ALL, 'zh_CN');
    $data =iconv('UTF-8','GBK//IGNORE',$data);
    header("Content-type:text/csv");
    header("Content-Disposition:attachment;filename=".$filename);
    header('Cache-Control:must-revalidate,post-check=0,pre-check=0');
    header('Expires:0');
    header('pragma:public');
    echo $data;
    exit;
}

mb_list_encodings();

mbstring 列出的编码集比 iconv 列出的编码较精简，

mbstring 虽然没有列出一些编码的子集，但是支持该子集。

比如只列出了 GB18030 ，但是却支持 GBK 和 GB2312。

列举所有已知的字符集 iconv -l

print_r(mb_list_encodings()); # 打印当前mbstring支持的编码
$enc = mb_detect_encoding($str, mb_list_encodings(), true); # 自动识别字符串的编码

2024-12-25

2025组机方案

需求

操作系统: win11
支持虚拟化: 是
AMD: 是
支持Win11: 是
支持PCIe 4.0: 是
是否超频: 否
集显: 是

检查

https://learn.microsoft.com/zh-cn/windows-hardware/design/minimum/supported/windows-11-supported-amd-processors

参考一:公司主机

CPU: i5-13500
内存: 三星 DDR4 1600 (非缓冲udimm)
主板: Q670
硬盘: NVMe INTEL SSDPEKNU512GZ (NVMe PCIe 3.0x4)

参考二:

参考三:

当前方案

CPU: AMD Ryzen 5 PRO 4650G
内存: 光威天策 DDR4 3200 32G x2
主板: B550 | X570
硬盘: 致态 2T
电源:
机箱:
散热: 九州风神
显示器: 小米27
键盘:
鼠标:
音响:

2024-10-18

phpstorm之HttpClient的使用tips

在输入请求头时, 要注意格式, 如下:

"feature/ultrabee110" ×

```
这是不规范的, 这样会把双引号都带入进去, 导致分支切换失败

正确的写法应该如下:
```text
Env-Tag: feature/ultrabee110 √

Choshui的博客

Choshui的博客

前端页面之table的优化

Workman5.0

布莱尔与点字法

记Windows下Gitea搭建

下载Gitea

执行并访问localhost:3000

注册为windows服务

nginx反向代理

Mysql之1118RowSizeTooLarge

场景

原因分析

解决方案

检查是否开启严格模式

数据表之碎片优化

Mysql之binlog

场景

1. 理解 MySQL Binlog Binlog 文件内容：

2. 查看和解析 Binlog 使用 mysqlbinlog 工具：

3. 数据恢复点-in-time 恢复：

编辑并重放 binlog：

4. 处理 Base64 编码的数据

5. 实用技巧与注意事项

结论

nginx踩坑之alias

场景

分析

解决问题

php-iconv

2025组机方案

需求

检查

参考一:公司主机

参考二:

参考三:

当前方案

phpstorm之HttpClient的使用tips

下载Gitea

执行并访问localhost:3000

注册为windows服务

nginx反向代理

场景

原因分析

解决方案

检查是否开启严格模式

数据表之碎片优化

场景

1. 理解 MySQL Binlog Binlog 文件内容：

2. 查看和解析 Binlog 使用 mysqlbinlog 工具：

3. 数据恢复 点-in-time 恢复：

编辑并重放 binlog：

4. 处理 Base64 编码的数据

5. 实用技巧与注意事项

结论

场景

分析

解决问题

需求

检查

参考一:公司主机

参考二:

参考三:

当前方案

3. 数据恢复点-in-time 恢复：