高可用优先选Galera Cluster，分库分表优先选Spider引擎，但二者不能混用；Galera提供多主强一致与自动故障切换，Spider仅作分片路由且不支持Go主流驱动的XA事务。
用Galera Cluster还是Spider引擎？选错直接影响事务一致性
直接结论：高可用优先选 Galera Cluster，分库分表优先选 Spider 引擎，但二者不能混用。Galera 是多主强一致集群，适合读写均衡、故障自动切换；Spider 是分片代理引擎，适合水平扩展写吞吐，但跨分片事务依赖 XA，而 Go 的主流 MySQL 驱动（如 go-sql-driver/mysql）不支持 XA 协议，实际无法开启分布式事务。
常见错误是把 Spider 当成 Galera 的“增强版”——Spider 不提供节点自动选举或 SST 同步能力，它只是路由层，后端挂了就查不到数据；而 Galera 本身不解决分库分表，所有表仍需手动建在每个节点上，无法按 user_id 自动路由到不同物理库。
- 若业务要求强一致性（如支付、库存扣减），必须用 Galera，并配合应用层分片路由（即 Go 代码自己算库/表，连对应节点）
- 若业务以写吞吐为主、能接受最终一致性（如日志、行为埋点），可选 Spider，但 SQL 中必须显式带分片键（如
WHERE user_id = 12345），不能用?占位符 - Galera 节点数建议为奇数（3 或 5），避免脑裂；Spider 的后端 MariaDB 实例必须独立部署，不能复用 Galera 节点
Go 客户端连接 Spider 时必须绕过物理库名
Go 应用不能直连 Spider 后端的真实数据库（如 orders_0），只能连 Spider 所在的逻辑库（如 shop）。连接字符串中的 database 参数必须填逻辑库名，否则 Spider 不识别路由规则。
典型错误配置：user:pass@tcp(10.0.1.10:3306)/orders_0 —— 这会绕过 Spider，报错 Table 'orders_0.orders' doesn't exist；正确写法是：user:pass@tcp(10.0.1.10:3306)/shop，且 SQL 中表名必须是逻辑表名（如 orders），不能写 orders_202406。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- SQL 查询必须含分片键字段，例如
SELECT * FROM orders WHERE user_id = 12345；用WHERE user_id = ?可能因驱动解析问题导致全库扫描 - Spider 默认关闭跨分片 JOIN，开启需配置
spider_use_consistent_snapshot=ON，但性能下降明显，不建议在高频查询中启用 - 连接池要单独为 Spider 实例初始化，别和 Galera 节点共用
*sql.DB，否则超时、重试策略互相干扰
在 DAO 层手动路由 Galera 分片时，事务边界必须严格对齐
Galera 本身不提供分片能力，所以 Go 服务得自己实现路由逻辑：根据分片键（如 user_id）选择具体节点，再执行 SQL。但 sql.Tx 天然绑定单个 *sql.DB，跨节点事务不可能靠 db.Begin() 实现 ACID。
真实落地中，90% 的跨库操作都得放弃原子性，改用补偿机制。比如用户下单+扣余额，必须确保两者落在同一 Galera 节点（用 user_id % 3 算出节点索引），否则就得引入本地消息表+定时任务对账。
- 每个 Galera 节点初始化独立的
*sql.DB，并调用SetMaxOpenConns和SetMaxIdleConns单独配置 - 表名不能硬编码，例如订单表得动态拼接：
"orders_" + strconv.FormatInt(userID%100, 10)，否则查不到数据 - 健康检查必须前置：启动时 ping 所有 Galera 节点，失败节点从路由 map 中剔除，避免运行时 panic
MaxScale 做读写分离时，Go 请求头 Host 字段容易被忽略
如果用 MaxScale 代理 Galera 集群做读写分离，Go 的 HTTP 客户端发请求到 MaxScale 时，req.Host 必须显式设置为 MaxScale 监听的虚拟域名（如 "db-proxy.local"），否则 MaxScale 无法匹配路由规则，可能把写请求转发到只读从库。
这不是 MariaDB 层面的问题，而是 MaxScale 的 [router] 配置依赖 Host 头做策略分发。Gin 或 Echo 中间件里修改 Host 是无效的，必须在 http.Request 构造阶段设置：
req, _ := http.NewRequest("GET", "http://db-proxy.local/orders", nil)
req.Host = "db-proxy.local" // 关键：不设这个，MaxScale 可能拒绝或误路由
- MaxScale 的
readwritesplit模块默认把无事务的 SELECT 转给从库，但显式开启事务（BEGIN）后所有语句都会走主库 - Go 的
http.Client默认复用连接，若 MaxScale 后端节点变更（如扩容），需重启 Go 服务或手动清空连接池，否则旧连接仍打向下线节点 - MaxScale 日志级别调成
debug时，能看清每条 SQL 被路由到了哪个后端，这是排查路由失效的第一手依据
Galera 和 Spider 都不解决“分片键变更”这个根本问题——一旦用户迁移到新分片，历史数据不动，应用层就得同时查新旧两个位置。这比连接配置更难绕过。
