# `newId` (function)

> 生成27位纯数字的ID 模仿后台Java代码生成


- **Type:** FUNCTION
- **Returns:** `varchar(32)`
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE FUNCTION `newId`'`._

## Narrative

**Business context:** 生成27位纯数字的ID 模仿后台Java代码生成 — canonical primary-key generator on the SQL side. Mirrors xly's Java-side `Sid.java` "all-numeric 27-char id" convention so a `CALL` inside a stored proc / form `sSqlStr` produces an `sId` indistinguishable from one minted by `BusinessBaseService.add(...)`. Whenever a routine has to insert a row but the caller didn't pass a guid, it uses this.

**What it does:** returns `CONCAT( DATE_FORMAT(NOW(),'%Y%m%d%H%i%s') , CEILING(RAND()*9e7+1e7) , CEILING(RAND()*9e9+1e9) )` — a 14-char timestamp prefix + an 8-digit and a 10-digit random suffix, producing 32 numeric digits as a `varchar(32)`. Caveat: collision probability is non-zero (RAND-based), and the catalog header claims 27 digits while the body yields 32 — the gap matters when callers truncate or hash the id.

**Invocation:** referenced by **137 stored routines** — every `Sp_Ai_*`, `Sp_addBtn_gdsmodle`, `sp_addCustomer`, `Sp_Add_Flow`, `Sp_Bill_Force_Complete`, `Sp_calc_*storeLimit`, `Sp_Calc_sWod`, `Sp_Cashier_*Journal`, `Sp_Check_s*` insert-path, `Sp_Con_*Reset`, `Sp_CostAccount_CostCarryForward`, `Sp_DailyStatisticalReport`, `init_plc_config`, `sendPlcData`, plus 4 forms (`sSqlStr` / `sConfigSqlStr` direct embeds). Java callers in xly-src: `SupplierInventoryServiceImpl`, `PlcServiceImpl`, `SearchGroupbyServiceImpl`. Also embedded in upgrade scripts under `script/标版/upgrade/`. Sibling: `NewId2`.