表
id uid info
1 1001 {"name":"週年慶","status":0,"addtime":"2017-10-10"}
2 1002 [ {"name":"週年慶","status":0,"addtime":"2017-10-11"},{"name":"特價促銷","status":0,"addtime":"2017-10-12"}]
3 1003 [ {"name":"特價促銷","status":0,"addtime":"2017-10-12"},{"name":"國慶促銷","status":0,"addtime":"2017-09-28"}]
查詢語句：select * from tb where info->'$.name' = '特價促銷' or JSON_CONTAINS(info->'$[*].name', '"特價促銷"', '$')
順便提一個問題：兩次查詢還是join查詢好？
曾遇到的一個慢sql調優，爲方便簡單寫：步驟一，
select tableA.id as ids from tableA where age>20;
步驟二，使用上一步的查詢結果：
select tableB.score from tableB where id in (ids);
這是一個很常見的查詢，步驟一和步驟二，相當於
select tableB.score from tableB inner join tableA on tableA.id=tableB.id;
爲什麼互聯網公司不讓使用join？
第一，不利於寫操作。執行讀操作時，會鎖住被讀的數據，阻塞其他業務對該部分數據的更新操作(U or D)。如果涉及多個聚合函數（緩存中沒有max or min時），相當於同時鎖住多張表，不能進行讀寫，直接影響其他業務，這影響了系統的整體性能；
第二，不利於維護。業務發生變動時，比如join中一張表改了，可能導致系統中原有的sql不可用，最終導致基於該SQL執行結果的上層顯示失敗（也意味着以往的開發工作已無效）。
如果不join呢？下面這個例子就不好了。
舉個例子你就明白了。比如，要統計2017年每個月的用戶訪問分佈量（沒訪問的佔比，訪問1-5次的佔比，訪問6-10次的佔比……）。這是一個簡單的連接問題（用戶表左連接訪問表）。用多表連接，你本可以從服務器端取回12行數據的（1-12月），結果你用了兩次單表查詢，從以上兩個表裏各取回了數萬乃至上百萬條數據，然後去做循環……這種程序員是腦殘吧？
結論: 分情況處理，小表業務量不大就一句inner join算了。維護就維護吧。
然後補一個好的模板去寫inner join 的sql句子。
SELECT
A.id AS AID,
A.content AS AContent,
B.id AS BID,
B.content AS BContent,
C.id AS CID,
C.content AS CContent
FROM
A
INNER JOIN B ON (A.id = B.id)
INNER JOIN C ON (A.id = C.id)