Spring Boot Config Files Explained: yml vs yaml, Load Order, Production Logging & SQL

yml and yaml: No Functional Difference

.yaml is the official standard extension; .yml is the industry shorthand. Functionality, syntax, parsing, and priority are identical. The author recommends standardizing on yml because 99% of projects use it.

Loading Priority: bootstrap > application

The iron rule: bootstrap loads first (before Spring container initialization), application loads later .

1. bootstrap.yml (Pre‑Startup System Config)

Highest priority, system‑level. Contains only four categories:

Service registry address (e.g., Nacos, Eureka)

Config center address (Nacos/Apollo)

Application name and environment identifier

Parameters that must be resolved before container starts

Characteristic: Once set, almost never overridden.

2. application.yml (Business Main Config)

Business‑level config loaded after bootstrap. Holds the familiar settings:

Port, context path

Database, Redis, MQ connections

Log levels, timeouts

Circuit breaker, rate limiting, business parameters

3. Environment‑Specific Files (dev / test / prod)

application-dev.yml

: Development application-test.yml: Testing application-prod.yml: Production

Override rule: Child environment config overrides the main application.yml. Example: if application.yml sets global log level to INFO and application-prod.yml sets it to WARN, production runs at WARN.

Top 3 Production Pitfalls: Why Your Config Changes Don't Take Effect

Pitfall 1: Changing Log Level in application.yml — No Effect

If the project uses a config center (Nacos, Apollo): Config center priority > all local yml files . Local edits are ignored; production follows the config center.

Pitfall 2: Editing prod File but Starting with dev Profile

If the startup command doesn't specify --spring.profiles.active=prod, the app defaults to dev. Your prod changes are never loaded.

Pitfall 3: bootstrap Locks Config, application Cannot Override

Registry and config center addresses placed in bootstrap.yml cannot be overridden by application.yml because bootstrap loads earlier and has higher precedence.

Production‑Grade Standard Config: Logging + SQL (No‑Crash Version)

1. Production Log Level Config ( application-prod.yml )

logging:
  level:
    # Global only WARN/ERROR to prevent massive logs causing GC
    root: WARN
    # Own business code keeps INFO for traceability
    com.xxx.biz: INFO
    com.xxx.controller: INFO
    # All frameworks/middleware forced to ERROR only
    org.springframework: ERROR
    org.mybatis: ERROR
    com.alibaba: ERROR
  file:
    path: /data/logs/laotang
    name: ${logging.file.path}/am.log
  pattern:
    file: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n"

Purpose: Avoids log‑induced GC pressure while retaining key business troubleshooting clues.

2. Production SQL Logging & Slow Query Config

mybatis:
  configuration:
    # Disable full SQL printing online to prevent IO/memory explosion
    log-impl: org.apache.ibatis.logging.nologging.NoLoggingImpl

logging:
  level:
    # Only log SQL errors; normal SQL not printed
    com.xxx.mapper: ERROR

Full SQL printing is disabled because it can saturate IO and memory. However, INFO‑level SQL is sometimes needed (e.g., debugging null‑pointer caused by missing join data).

3. MySQL Server‑Side Slow Query Standard

slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1
slow_query_log_file = /var/log/mysql/slow.log
general_log = 0

Ultimate Checklist: Troubleshooting Config in This Order

Check Environment: Is the service running dev or prod?

Check Priority: Config Center > bootstrap > local prod > main config.

Log Issues: Production only WARN + core INFO; no DEBUG, no full SQL.

Latency/Timeout: Check MySQL slow query log first, don't obsess over app logs.

Config Not Effective: 99% chance it's overridden by a higher‑priority config. Don't doubt your code; trace the config chain.