some SQL Usage Issues:

I started using version 1.6 of zabbix. The current size of the ZABBIX cluster should be the largest in the world. I like it.

zabbix3.0.10 upgrade to zabbix4.0.10，when Change table structure,SQL too shit，For example：

alter table `items` add `post_type` int(11) NOT NULL DEFAULT '0';
alter table `items` add `http_proxy` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '';
alter table `items` add `headers` text COLLATE utf8mb4_general_ci NOT NULL;
alter table `items` add `retrieve_mode` int(11) NOT NULL DEFAULT '0',
alter table `items` add `request_method` int(11) NOT NULL DEFAULT '0';
alter table `items` add `output_format` int(11) NOT NULL DEFAULT '0';
alter table `items` add `ssl_cert_file` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '';
alter table `items` add `ssl_key_file` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '';
alter table `items` add `ssl_key_password` varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '';
alter table `items` add `verify_peer` int(11) NOT NULL DEFAULT '0';
alter table `items` add `verify_host` int(11) NOT NULL DEFAULT '0';
alter table `items` add `allow_traps` int(11) NOT NULL DEFAULT '0';

i think,one table change,one SQL is good,The above statement can this write:

alter table `items` add `post_type` int(11) NOT NULL DEFAULT '0',
add `http_proxy` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
add `headers` text COLLATE utf8mb4_general_ci NOT NULL,
add `retrieve_mode` int(11) NOT NULL DEFAULT '0',
add `request_method` int(11) NOT NULL DEFAULT '0',
add `output_format` int(11) NOT NULL DEFAULT '0',
add `ssl_cert_file` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
add `ssl_key_file` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
add `ssl_key_password` varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
add `verify_peer` int(11) NOT NULL DEFAULT '0',
add `verify_host` int(11) NOT NULL DEFAULT '0',
add `allow_traps` int(11) NOT NULL DEFAULT '0';

This is very important，In the process of upgrading, there are many problems like this. 

For thousands of monitoring instances, the amount of data is very large, especially in the early version of MySQL, which does not support online change table structure, so the upgrade time will be very long. I think it's unacceptable for operators. I think it's very foolish to write such a statement. I don't have any common sense of operation and maintenance. I don't know about databases. I look forward to resolving these problems as soon as possible, otherwise it will bring great challenges to operation and maintenance.