MySQL

背景 在支付系统：MySQL 分片 我们讨论了如何进行分库分表。 由于各种原因，我们的数据库负载会随着时间的推移而增加，比如： 用户数量和流量的增长。

I was working at a payment service team from 2019-2021. The blog is based on my experience at that time. 在支付系统中，数据库则是最容易产生性能瓶颈的组件。 在本文中，我们将讨论支付服务是如何在大规模下对My

支付系统的一大挑战：高并发下怎么做余额扣减；并发扣款，如何保证数据的一致性？ 高并发扣减思路 分库分表 合并请求，在保证事务的前提下，将多个扣款请

Show MySQL processlist SHOW FULL PROCESSLIST Check Binlog show variables like 'log_bin' show tables SHOW TABLES command provides you with an option that allows you to filter the returned tables using the LIKE operator or an expression in the WHERE clause as follows: SHOW TABLES LIKE pattern; SHOW TABLES WHERE expression; > SHOW TABLES LIKE 'p%'; +------------------------------+ | Tables_in_testdb (p%) | +------------------------------+ | productlines | | products | +------------------------------+ 2

数据库长连接 长连接是指程序之间的连接在建立之后，就一直打开，被后续程序重用。使用长连接的初衷是减少连接的开销。 先看看官方文档是怎么讲Djan

为了解决单个数据库的性能问题，除了使用性能更好的硬件之外， 另外一个思路就是将一个数据库切分成多个部分放到不同的数据库上，从而缓解单一数据库的

Django ORM没有提供默认的分表功能，给访问分表的数据库带来的不变。那么Django分表怎么实现呢？ 分析Django ORM 在实现具体的方案之前，我们先

索引失效的情况 create payment table: create table payment_tab { `id` bigint unsigned auto_increment, `payment_id` bigint unsigned not null, `user_id` bigint unsigned not null, `create_time` int unsigned not null, `update_time` int unsigned not null default 0, `amount` bigint not null default 0, `payment_status` tinyint not null default 0, `ref` varchar(64) default NULL, `payment_type` tinyint not null default 0, primary key (`id`), -- 主键 `idx_user_id` (`user_id`),