SaaS应用分库分表笔记

子曰：“盖有不知而作之者，我无是也。多闻，择其善者而从之，多见而识之，知之次也。”经常让手下做事情，下属很快搞出一个设计方案，一问原来这个方案是他自己想出来的。你能说他方案设计的不行吗，那不是打击他的积极性吗，他确实做了些事情，但并没有用心。这就是孔子所讲的“不知而作之”，做事情并不是都是自己创造，特别是我们这些搞计算机的，我不是电信、BAT、金蝶、用友等，我们想到的很多人都已经有过实践了，自己设计的方案或许是对的，终将只是停留在“见山是山”的层面，没有经过横向对比，选取最佳实践，也就是“多闻，择其善者而从之”，这才是正确做事情的办法。可惜的是很多搞技术的人员并不明白。“中人以上，可以语上也。中人以下，不可以语上也。”我能说什么呢，做到一定程度就可以了。逼他们接受这些观点，还是算了，点到为止即可。
我这里在行动起来，多看看别人分库分表是怎么做的，毕竟saas水平扩展最麻烦的环节还是数据库层面。
亿级流量网站核心技术
3 分表后排查问题, 如何快速找到对应的表
因为分表了，存在数据丢失，虽然可以根据分表规则来做，但是担心有些数据，如果是单页应用，结果数据跑到表中，就会有问题，于是写一个mysql存储过程

DELIMITER //
drop procedure if EXISTS check_voucher;
create procedure check_voucher()
BEGIN
	DECLARE i int;
	declare cn int;
	set i = 0;
	set @cn = 0;
	while i<50 DO
		-- set @sql = CONCAT('select count(*) into @cn from acc_voucher_entry_',i," where credit_amount='781601.98'");
		set @sql = CONCAT('select count(*) into @cn from acc_voucher_',i," where as_id=25309");
		prepare stmt from @sql;
		execute stmt ;
		DEALLOCATE prepare stmt;
 		if (@cn>0) then
 			-- 打印数据在那个表
 			select i;
 		end if;
		set i=i+1;
	end while;
END
//
DELIMITER ; 

调用存储过程

call check_voucher()

2 mysql优化
给代账公司从0到1设计一套财务软件，才知道不能按照项目的方式，性能非常重要。一家代账公司可以代理800~1000家企业的账套。
2.1 PERFORMANCE_SCHEMA
mysql5.5之后使用这个表，在未上线之前把功课做足
Mysql分析监控之Performance_schema SQL执行统计

-- 查看是否开启performance_schema
show variables like 'performance_schema';

执行结果中带*的是有全表扫描的，需要优化

-- 查看执行频繁的sql
SELECT
	digest_text AS sql_text,
	count_star AS exec_count,

IF (
	sum_no_good_index_used > 0
	OR sum_no_index_used > 0,
	'*',
	''
) AS full_scan,
 sum_created_tmp_tables AS tmp_tables,
 sum_created_tmp_disk_tables AS tmp_disk_tables,
 sum_sort_rows AS rows_sorted
FROM
	events_statements_summary_by_digest
WHERE
	schema_name = 'acc_test_2021062801'
AND digest_text LIKE 'select%'
ORDER BY
	count_star DESC
LIMIT 10;

2.2 @@session.tx_read_only
使用jprofiler，查看到select @@session.tx_read_only占用了37%的时间，
USELOCALSESSIONSTATE作用
高版本的mysql，参见添加链接描述

再次执行同样的操作，它还是会出现

添加jdbc:mysql://192.168.0.1:3306/acc_test_2021062801?characterEncoding=UTF-8&useLocalSessionState=true之后，&useLocalSessionState=true这个参数确实起到作用了，减少了1.3s的时间，但是会带来其他的不良影响吗?

Spring的@Transactional(readOnly=true)注解

1 动态数据源

<dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
            <version>3.3.6</version>
        </dependency>

配置如下

 datasource:
    dynamic:
      hikari: # 全局hikariCP参数
        minimum-idle: 100 #最小空闲连接数量
        idle-timeout: 120000 #空闲连接存活最大时间，默认600000（10分钟）
        maximum-pool-size: 200 #连接池最大连接数，默认是10
        auto-commit: true  #此属性控制从池返回的连接的默认自动提交行为,默认值：true
        max-lifetime: 1800000 #此属性控制池中连接的最长生命周期，值0表示无限生命周期，默认1800000即30分钟
        connection-timeout: 30000 #数据库连接超时时间,默认30秒，即30000
        connection-test-query: SELECT 1
      datasource:
        master:
          driver-class-name: com.mysql.cj.jdbc.Driver
          url: jdbc:mysql://10.8.15.235:3306/eayc?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=UTC
          username: root
          password: ENC(密码)
          type: com.zaxxer.hikari.HikariDataSource