//闰年最直接的判断是:能被4整除且不能被100整除,或者能被400整除的年份 create or replace procedure pro_leap_year(year_in
//闰年最直接的判断是:能被4整除且不能被100整除,或者能被400整除的年份
create or replace procedure pro_leap_year(year_in in number)
as
v_mod1 number(4) :=mod(year_in,4);
v_mod2 number(4) :=mod(year_in,100);
v_mod3 number(4) :=mod(year_in,400);
begin
if ((v_mod1=0 and v_mod20) or v_mod3=0) then
dbms_output.put_line(year_in||' is a leap year');
else dbms_output.put_line(year_in||' is not a leap year');
end if;
exception
when others then
dbms_output.put_line(sqlerrm);
end pro_leap_year;
/
SQL> exec pro_leap_year(2010);
2010 is not a leap year
PL/SQL procedure successfully completed
//
SQL> exec pro_leap_year(2000);
2000 is a leap year
PL/SQL procedure successfully completed
//
//关于闰年平年,下面有一个比较全面的解释:
//在公历(格里历)纪年中,,有闰日的年份叫闰年,一般年份365天,闰年为366天。
//由于地球绕太阳运行周期为365天5小时48分46秒(合365.24219天)即一回归年,公历把一年定为365天。
//所余下的时间约为四年累计一天,加在二月里,所以平常年份每年365天,二月为28天,闰年为366天,二月为29天。
//因此,每400年中有97个闰年,闰年在2月末增加一天,闰年366天。
//闰年的计算方法:公元纪年的年数可以被四整除,即为闰年;
//被100整除而不能被400整除为平年;被100整除也可被400整除的为闰年。
//如2000年是闰年,而1900年不是。
//
//我们所关心的是怎么样计算指定的一个年份是否是闰年:
//从上面的描述中,我们知道:
//如果一年中2月份有29天,那么这一年就是闰年,否则是平年
SQL> drop procedure pro_leap_year;
Procedure dropped
//
create or replace procedure pro_leap_year(year_in in number)
as
v_year_in varchar2(10) :=to_char(year_in)||'0229';
v_date date;
begin
//这里将拼接的字符串转换为日期,并赋值给一个日期类型的变量,
//其实就是为了和日期类型进行比较,隐式的比较,比较你输入的年份中2月是否含有29日这一天
v_date :=to_date(v_year_in,'yyyy-mm-dd');
dbms_output.put_line(year_in||' is a leap year');
exception
when others then
dbms_output.put_line(year_in||' is not a leap year');
end pro_leap_year;
/
SQL> exec pro_leap_year(2010);
2010 is not a leap year
PL/SQL procedure successfully completed
//
SQL> exec pro_leap_year(2000);
2000 is a leap year
PL/SQL procedure successfully completed
//
SQL> exec pro_leap_year(2005);
2005 is not a leap year
PL/SQL procedure successfully completed
//
SQL> exec pro_leap_year(2100);
2100 is not a leap year
PL/SQL procedure successfully completed
//
//我们也可以用一条select语句来判断:
SQL> select case
2 when to_char(last_day(to_date(&year||'02','yyyymm')),'dd')='29'
3 then 'the year you input is a leap year'
4 else 'the year you input is not a leap year'
5 end is_leap_year
6 from dual;
Enter value for year: 2050
old 2: when to_char(last_day(to_date(&year||'02','yyyymm')),'dd')='29'
new 2: when to_char(last_day(to_date(2050||'02','yyyymm')),'dd')='29'
IS_LEAP_YEAR
-------------------------------------
the year you input is not a leap year
//
SQL> /
Enter value for year: 2000
old 2: when to_char(last_day(to_date(&year||'02','yyyymm')),'dd')='29'
new 2: when to_char(last_day(to_date(2000||'02','yyyymm')),'dd')='29'
IS_LEAP_YEAR
---------------------------------
the year you input is a leap year
//
SQL> /
Enter value for year: 2012
old 2: when to_char(last_day(to_date(&year||'02','yyyymm')),'dd')='29'
new 2: when to_char(last_day(to_date(2012||'02','yyyymm')),'dd')='29'
IS_LEAP_YEAR
---------------------------------
the year you input is a leap year
//
SQL> /
Enter value for year: 1998
old 2: when to_char(last_day(to_date(&year||'02','yyyymm')),'dd')='29'
new 2: when to_char(last_day(to_date(1998||'02','yyyymm')),'dd')='29'
IS_LEAP_YEAR
-------------------------------------
the year you input is not a leap year
//

Stored procedures are precompiled SQL statements in MySQL for improving performance and simplifying complex operations. 1. Improve performance: After the first compilation, subsequent calls do not need to be recompiled. 2. Improve security: Restrict data table access through permission control. 3. Simplify complex operations: combine multiple SQL statements to simplify application layer logic.

The working principle of MySQL query cache is to store the results of SELECT query, and when the same query is executed again, the cached results are directly returned. 1) Query cache improves database reading performance and finds cached results through hash values. 2) Simple configuration, set query_cache_type and query_cache_size in MySQL configuration file. 3) Use the SQL_NO_CACHE keyword to disable the cache of specific queries. 4) In high-frequency update environments, query cache may cause performance bottlenecks and needs to be optimized for use through monitoring and adjustment of parameters.

The reasons why MySQL is widely used in various projects include: 1. High performance and scalability, supporting multiple storage engines; 2. Easy to use and maintain, simple configuration and rich tools; 3. Rich ecosystem, attracting a large number of community and third-party tool support; 4. Cross-platform support, suitable for multiple operating systems.

The steps for upgrading MySQL database include: 1. Backup the database, 2. Stop the current MySQL service, 3. Install the new version of MySQL, 4. Start the new version of MySQL service, 5. Recover the database. Compatibility issues are required during the upgrade process, and advanced tools such as PerconaToolkit can be used for testing and optimization.

MySQL backup policies include logical backup, physical backup, incremental backup, replication-based backup, and cloud backup. 1. Logical backup uses mysqldump to export database structure and data, which is suitable for small databases and version migrations. 2. Physical backups are fast and comprehensive by copying data files, but require database consistency. 3. Incremental backup uses binary logging to record changes, which is suitable for large databases. 4. Replication-based backup reduces the impact on the production system by backing up from the server. 5. Cloud backups such as AmazonRDS provide automation solutions, but costs and control need to be considered. When selecting a policy, database size, downtime tolerance, recovery time, and recovery point goals should be considered.

MySQLclusteringenhancesdatabaserobustnessandscalabilitybydistributingdataacrossmultiplenodes.ItusestheNDBenginefordatareplicationandfaulttolerance,ensuringhighavailability.Setupinvolvesconfiguringmanagement,data,andSQLnodes,withcarefulmonitoringandpe

Optimizing database schema design in MySQL can improve performance through the following steps: 1. Index optimization: Create indexes on common query columns, balancing the overhead of query and inserting updates. 2. Table structure optimization: Reduce data redundancy through normalization or anti-normalization and improve access efficiency. 3. Data type selection: Use appropriate data types, such as INT instead of VARCHAR, to reduce storage space. 4. Partitioning and sub-table: For large data volumes, use partitioning and sub-table to disperse data to improve query and maintenance efficiency.

TooptimizeMySQLperformance,followthesesteps:1)Implementproperindexingtospeedupqueries,2)UseEXPLAINtoanalyzeandoptimizequeryperformance,3)Adjustserverconfigurationsettingslikeinnodb_buffer_pool_sizeandmax_connections,4)Usepartitioningforlargetablestoi


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SublimeText3 Linux new version
SublimeText3 Linux latest version

Dreamweaver Mac version
Visual web development tools

WebStorm Mac version
Useful JavaScript development tools

PhpStorm Mac version
The latest (2018.2.1) professional PHP integrated development tool

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software
